How I built a Customer Care AI Agent that actually remembers your problem

Mehmooda Mohiuddin — Tue, 29 Sep 2026 02:41:31 +0000

Most customer-support systems remember the conversation.

That isn't necessarily enough.

If a customer comes back with the same problem a week later, the useful question isn't just “What did we talk about last time?” It is “What did we actually try, and what happened when we tried it?”

That distinction became the foundation for Relay, a memory-powered customer-support agent that remembers previous troubleshooting attempts and their outcomes.

Instead of treating every conversation as a fresh start, Relay builds a history of the case and uses that history when deciding what to do next.

The problem with starting from zero

Imagine a customer contacting support because their Wi-Fi keeps disconnecting.

The support agent suggests restarting the router.

It works.

For about twenty minutes.

The customer contacts support again.

A normal conversational agent might see the previous messages and still suggest restarting the router because it is a common troubleshooting step.

But from the customer's perspective, that is frustrating.

They already tried it.

What matters is not simply that “restart the router” appeared in the conversation.

What matters is that:
Restarting the router was already tried, and the result was temporary.

Later, perhaps a driver update fixes the problem completely.

Now Relay has something much more useful than a transcript.

It has a case history:

Problem:
Wi-Fi disconnecting

Attempt 1:
Restart router
→ Temporary improvement

Attempt 2:
Update network driver
→ Problem resolved

The next time a similar problem appears, Relay can use that history.

Relay remembers the case, not just the conversation

That became the core idea behind Relay.

Instead of thinking about memory as simply storing previous messages, we wanted memory to influence what the agent does next.

The basic workflow looks like this:

Customer
   ↓
Relay
   ↓
Recall relevant case history
   ↓
Reason about previous outcomes
   ↓
Choose next troubleshooting step
   ↓
Customer responds
   ↓
Store the new outcome
   ↓
Relay learns from the interaction

The important part is the loop.

A conversation doesn't simply end after the response.

Its outcome becomes useful information for future interactions.

Why Hindsight?

We used Hindsight as Relay's memory layer.

Hindsight provides the mechanisms we need to retain information, recall relevant memories, and reason over those memories.

Hindsight GitHub

Hindsight Documentation

For Relay, this means we can separate the support agent's conversational logic from its long-term memory.

When something important happens during a support interaction, Relay can retain it.

When another relevant problem appears later, Relay can recall information from previous interactions.

The important thing is that the retrieved information isn't just displayed to the user.

It influences the next decision.

Retaining outcomes is more useful than retaining transcripts

One design decision we kept coming back to was what Relay should actually remember.

A transcript contains everything:

Customer: My Wi-Fi keeps disconnecting.

Agent: Try restarting your router.

Customer: Okay, it works now.

Agent: Great!

But a future support interaction doesn't necessarily need the entire conversation.

It needs the useful facts extracted from it.

For example:

Issue: Wi-Fi disconnecting

Attempt:
Router restart

Outcome:
Temporary improvement

That distinction is important because troubleshooting is fundamentally about experiments.

You try something.

You observe the result.

Then you decide what to try next.

Relay's memory therefore needs to preserve those outcomes.

The second interaction is where memory matters

The first interaction demonstrates that Relay can create memory.

The second interaction demonstrates why that memory exists.

Suppose the same customer returns later.

Instead of treating the problem as completely new, Relay can retrieve the previous case.

It can see that restarting the router had already been attempted and only helped temporarily.

It can also see that another solution previously resolved the issue.
That changes the response.

The agent doesn't have to blindly start from the beginning.

It can build on what happened before.

This is the behavior we wanted to demonstrate with Hindsight: memory changing the agent's behavior over time.

The troubleshooting loop

Relay's reasoning can be thought of as a continuous loop:

New problem
     ↓
Recall relevant history
     ↓
Understand previous attempts
     ↓
Choose next action
     ↓
Observe outcome
     ↓
Retain outcome
     ↓
Problem solved?
   ↙       ↘
 Yes        No
 ↓           ↓
Remember    Continue
success     reasoning
             ↓
       Useful options left?
          ↙       ↘
        Yes        No
        ↓           ↓
      Retry      Escalate

This is particularly useful for support because failure itself is information.

A failed troubleshooting step shouldn't disappear.

It should help constrain what the agent tries next.

When AI should stop troubleshooting

Another part of Relay is knowing when continued automated troubleshooting may no longer be useful.

If relevant troubleshooting attempts have already been exhausted, Relay can recommend escalating the issue to a technician rather than continuing to repeat generic suggestions.

The important part is that escalation is based on the history of the case.

It isn't simply:

“The first solution didn't work, so contact a technician.”

Instead, the agent considers what has already been attempted and whether useful options remain.

That makes escalation part of the memory loop as well.

The outcome can itself become part of the case history.

What changed after adding memory?

Without persistent case memory, an agent tends to behave like this:

Problem
↓
Suggest solution
↓
Conversation ends
↓
New conversation
↓
Problem looks new
↓
Suggest common solution again

With memory:

Problem
↓
Suggest solution
↓
Observe outcome
↓
Remember outcome
↓
New conversation
↓
Recall previous case
↓
Avoid previous unsuccessful/temporary step
↓
Choose a more informed next action

That difference is the actual reason Relay needs memory.

The goal isn't to make the chatbot remember more messages.

The goal is to make the agent make better-informed decisions because it remembers what happened before.

What I learned building Relay

1. Memory needs a purpose
Adding a memory system simply because an application is an AI agent isn't enough.

We needed to answer:
What changes because the agent remembers?
For Relay, the answer is troubleshooting decisions.

2. Failed attempts are valuable data
In a support workflow, failure isn't useless information.

If a solution has already been tried and didn't solve the problem, that should affect the next action.

3. The second interaction is more important than the first
The first interaction proves that information can be stored.

The later interaction proves that the stored information actually matters.

That's where the value of agent memory becomes visible.

4. Memory should connect to outcomes
Remembering that a customer said something is less useful than remembering what happened after an action.

For troubleshooting, the outcome is often the most important part.

What Relay is really trying to solve

Customer support shouldn't have to rediscover the same problem every time a customer returns.

A support agent should be able to build on previous attempts instead of repeatedly starting from zero.

That's the idea behind Relay.

Relay remembers the case, not just the conversation.

And with Hindsight providing persistent agent memory, the support agent can use previous experiences to inform what it does next.

Learn more about agent memory from Vectorize
https://vectorize.io/what-is-agent-memory

DEV Community: Mehmooda Mohiuddin