I Built a Support Agent That Remembers What Failed

AFREEN FASIHA — Wed, 30 Sep 2026 02:23:37 +0000

We Built a Support Agent That Remembers What Failed

A support agent can answer a question perfectly and still be frustrating to use.

The problem starts when the customer comes back.

They have already explained the device, described the issue, restarted something, tried another fix, and reported what happened. A stateless assistant sees a new message. The customer sees the same unresolved problem.

We built MemoryDesk to explore a different approach: make the agent remember the useful parts of previous support interactions and use those memories to decide what to do next.

The key idea is simple:

A returning customer should not have to start over.

The problem with ordinary support conversations
Consider a customer with a recurring Wi-Fi problem.

On the first interaction, they might say:

“My Dell laptop keeps disconnecting from Wi-Fi. I already restarted the router, but the problem is still there.”

A conventional chatbot can answer that message. It can suggest restarting the router, checking the connection, or running a network diagnostic.

But the router has already been restarted.

That matters.

If the customer returns later and says:

“Hey, it’s happening again.
A useful support agent needs more than the latest message. It needs the history that changes what the next action should be.

That became the design constraint for MemoryDesk: remember useful context, not just chat transcripts.

How We Built the Memory Layer
We used Hindsight as the persistent memory layer.

The application sends the customer interaction to Hindsight with retain:

TypeScript

await hindsight.retain(
BANK_ID,
Customer ${customerId} said: ${message},
{
context: "MemoryDesk customer support conversation",
metadata: {
customerId
}
}
);
For a later message, MemoryDesk asks Hindsight to recall context that is relevant to the current issue:

TypeScript

const recall = await hindsight.recall(
BANK_ID,
What useful previous support context do we know about customer ${customerId} that is relevant to this issue: ${message},
{
maxTokens: 3000,
budget: "mid"
}
);
Then the agent uses that accumulated context when generating its response.

That separation matters to the product design. The chat interface does not need to expose raw memory records every time someone sends a message. Memory can work in the background, while a dedicated History view lets the user inspect it when they actually need it.

The implementation uses the Hindsight GitHub repository and the Hindsight API/client to connect the support workflow to persistent memory. We also kept the main application lightweight: React and Vite on the frontend, Node.js and Express on the backend.

For more background, we found Vectorize's explanation of agent memory useful when thinking about what information should persist across interactions.

The important part: memory has to change the answer

The easiest way to fake a memory feature is to show a list called “Memories”.

That is not what we wanted.

The useful test is whether the answer changes because of what the agent remembers.

Without useful memory

Customer:

“Hey, it’s happening again.”

Agent:

“Could you describe the issue and tell me what troubleshooting steps you have already tried?”

Technically reasonable. Operationally repetitive.

With relevant memory

Customer:

“Hey, it’s happening again.”

MemoryDesk can respond more like:

“Hey, welcome back! I remember we were troubleshooting the Wi-Fi issue on your Dell laptop, and restarting the router didn’t solve it. Let’s pick up from there.”

The important difference is not that the second answer contains more words.

It is that the agent knows what not to repeat.

That gives it a better starting point for the next diagnostic step.

**
Making the interaction feel human**

Persistent memory is a technical feature. The customer should not have to think about the implementation.

That is why MemoryDesk separates three layers of the experience.

The chat is conversational. It uses short responses, focused questions, and natural language.

The profile shows current support context such as the selected device and issue.

The History tab exposes the persistent memory only when the user asks to see it.

This keeps the primary support experience clean while making the memory layer visible and understandable.

We also added device and issue selection at the start of a session. That gives the agent initial context without forcing the customer to type everything in a rigid form.

What surprised us while building it

The most useful memory is not necessarily the longest memory.

A long conversation transcript is not automatically good support context.

What matters is whether the agent can recover the facts that affect its next decision:

What device is involved? 
What problem keeps happening? 
What has already been tried? 
Did that attempt work? 
What new clue appeared later? 
That changed how we thought about the memory layer. We stopped treating memory as “chat history” and started treating it as support history.

*One limitation we had to account for
*
There is a trade-off between showing memory everywhere and keeping the interface readable.

During early testing, displaying every recalled memory beside every response made the conversation feel cluttered. The information was technically useful, but the experience was worse.

We changed the design so memory stays in the background during normal conversation and appears in a dedicated History tab.

That turned out to be a better product decision: the agent can use memory constantly without forcing the customer to look at it constantly.

What we learned..
1. Memory should influence decisions
If an agent remembers something but still gives the same generic answer, the memory layer is not doing enough.

2. Failed actions are valuable context
Knowing that a troubleshooting step already failed can be more useful than knowing what the customer said word-for-word.

3. Good AI UX hides unnecessary complexity
The customer should experience continuity, not API calls, retrieval steps, or internal processing.

4. A small workflow is enough to prove the idea
MemoryDesk focuses on one workflow: recurring technical support. That makes the memory behavior easier to see and test.

Where we would take it next
A production version could connect MemoryDesk to a real support-ticket system and carry context across email, chat, and human-agent handoffs.

It could also separate short-term conversation context from longer-term customer memory, add stronger access controls, and provide better tools for reviewing or correcting stored information.

Those would be important steps before using a system like this with real customer data.

For now, the core lesson is enough:

The best part of agent memory is not that the agent remembers your past. It is that your past changes what it does next.

That’s the idea behind MemoryDesk.

DEV Community: AFREEN FASIHA

I Built a Support Agent That Remembers What Failed