Your customer already told you. Does your agent remember?

Cisco wants its service agents to remember every customer across channels and across weeks. Remembering is the easy part. Deciding what gets kept, and who holds it, is the work.

What happened

At WebexOne this week, Cisco announced a batch of AI features for Webex, including Claude agents that work inside Webex and an assistant for meeting rooms. For anyone running customer service, the item to read is Dialog, which Cisco pitches as the basis for "personalized, long lasting customer relationships."

According to the announcement, Dialog joins customer history with enterprise data to keep context "across all channels and time." Its agents keep working on a customer's behalf after the conversation ends, and they refine themselves from customer journeys and from the judgment of human agents. Cisco gave no ship date.

Why this matters to your business

The oldest complaint in support is having to repeat yourself. A customer explains the problem on chat on Monday, then calls on Wednesday and has to explain it again to someone who has never heard of them. Every repeat costs you handle time and costs them patience, and the second explanation is usually angrier than the first.

Most AI agents in production make this worse. They start every conversation with a blank page, and when the session closes, whatever the customer said goes with it. Cisco is betting that memory is what buyers will pay for next, and on that point it's probably right.

Memory raises two questions a feature list doesn't answer. The first is what the agent should keep. A warranty claim, a promised callback and a preferred contact time are worth keeping. A card number, a complaint about a neighbour or a health detail mentioned in passing are not, and in several jurisdictions holding them is a liability you didn't mean to take on. The second is where the memory lives. Years of customer context built up inside one vendor's platform become part of what you'd have to rebuild if you ever left.

Why this is a CX-Builder use case

The shape is simple to describe. Before the agent says anything, it reads a short file on the customer, and when the conversation ends, it writes back to that file. The file holds what a careful human agent puts in the notes field: what's open, what was tried, what was promised and how the customer likes to be contacted. The full transcript stays out of it. Past tickets sit beside the file in a searchable store, so the agent can pull the one earlier case that matters instead of reading the whole history.

CX-Builder builds this with the memory and retrieval it already has, against a database you run. Because it's self-hosted, the customer file sits on your own infrastructure and stays there when you change the model or the channel. You write the rules for what gets saved, and a person can read them.

The same file covers Cisco's idea of an agent that keeps working after the call. If the agent promised to check on a refund by Friday, that promise is a field with a date on it, and a scheduled flow can pick it up. Anything that moves money still goes to a person to approve.

What this looks like if you build it

One agentflow that starts by looking the customer up from a verified identifier, such as the logged-in account or the number the call came from, and never from a name typed into the chat. It loads their profile and open cases, then runs retrieval over past tickets filtered to that customer, so one person's history can't surface in another person's answer.

At the end of the conversation, a summarising step writes a handful of fields back: the open issue, any promise made and its date, the next step, and who owns it. Before the write happens, a filter strips card numbers and anything else you've decided never to store. For the first month, those write-backs pass through a human-in-the-loop review, so a team lead sees what the agent thinks is worth remembering and can correct it.