I Built an Agent That Remembers What Users Complained About

BAVUGARI CHARAN KUMAR — Sun, 27 Sep 2026 13:17:58 +0000

Introduction

Most product teams collect a lot of feedback.

Customers report bugs.
Support teams receive complaints.
Developers fix issues.
Product managers make decisions.
New releases are deployed.

But there is one problem:

Companies can remember information without actually remembering the context behind it.

A bug may have been fixed six months ago. The developer who worked on it may have moved to another team. A new developer may see a similar complaint and assume that it is a completely new problem.

I wanted to build a system that could connect these pieces of history.

That idea became ReTrace — The AI User Feedback Memory Engine.

Instead of only asking:

"What are customers complaining about?"

ReTrace tries to answer:

"Have we seen this problem before, what did we do about it, who was responsible, and what happened afterward?"

The Problem: Products Forget Their Own History

Consider a simple example.

In March, a customer reports:

"The checkout page freezes when I try to make a payment."

The engineering team investigates it.

From Feedback Dashboard to Product Memory

ReTrace tries to connect the information:

                    New Feedback
                         ↓
            Similar Historical Feedback
                         ↓
                   Previous Bug
                         ↓
                    Previous Fix
                         ↓
                  Product Release
                         ↓
                   Previous Owner
                         ↓
                Current Ownership
                         ↓
                    New Evidence

This gives the product team more context before deciding what to do.

The idea is not to replace the product team.

It is to make the organization's historical information easier to understand.

Why I Needed Long-Term Memory

This is where Hindsight becomes important.

I use Hindsight as the long-term memory layer for ReTrace.

Hindsight provides three important operations:

Retain — store important information in memory.
Recall — retrieve relevant information later.
Reflect — reason over remembered information.

You can learn more about Hindsight from its GitHub repository.

Conceptually, ReTrace works like this:

             Customer feedback
                     ↓
                   RETAIN
                     ↓
            Hindsight Memory
                     ↓
                   RECALL
                     ↓
            Historical information
                     ↓
                  REFLECT
                     ↓
            Historical reasoning

For example, when a new complaint arrives, the system can retain the new feedback.

Later, when we need to investigate it, ReTrace can recall related historical information.

The agent can then reason over the old and new information.

How ReTrace Stores Feedback

A simplified version of retaining feedback looks like this:

from hindsight_client import Hindsight

client = Hindsight("http://localhost:8888")

``feedback = """
Customer reported that the checkout page freezes
when attempting to complete payment.
"""

client.retain(
bank_id="retrace",
content=feedback
)``

The important part here is not just storing the text.

The goal is to create useful long-term memory that can later be searched and connected with other information.

For example, we may eventually have memories about:

                   Customer feedback
                           +
                     Bug reports
                           +
                     Product releases
                           +
                     Previous fixes
                           +
                       Ownership
                           +
                    Product decisions

This is what makes historical reasoning possible.

Detecting Product Déjà Vu

One of the main features of ReTrace is what I call the Déjà Vu Detector.

The question is simple:

"Have we already seen this problem?"

Suppose the system receives:

"The payment page gets stuck after entering card details."

ReTrace searches its memory.

It may find:

                      Current feedback
                             ↓
                 "Payment page gets stuck"

                    Historical feedback
                             ↓
               "Checkout freezes during payment"

                        Previous bug
                             ↓
                          BUG-102

                       Previous fix
                             ↓
                           v1.4

                      Previous owner
                             ↓
                           Priya

Instead of simply saying:

"These two sentences are similar."

the system can provide historical context.

That is much more useful to a product team.

Remembering Ownership

Another part of my current design is tracking who was responsible for an issue or decision.

For example:

Issue:
Checkout payment freeze

Original owner:
Priya

Team:
Payments

Fix:
v1.4

Later, the ownership may change.

                                Priya
                                  ↓
                        moves to another team
                                  ↓
                             Payments issue
                                  ↓
                              new owner

The historical information still exists, but the original context may no longer be directly available from the same person.

This creates an important question:

Should an old decision always be trusted in exactly the same way?

My design explores this through the idea of ownership-based confidence.

Ownership-Based Confidence

This is one of the deeper ideas behind ReTrace.

Imagine the system has the following historical belief:

"The checkout payment problem was fixed."

The system may have:

Statement:
Checkout payment problem was fixed.

Evidence:
v1.4 release

Original owner:
Priya

Confidence:
91%

Now imagine that Priya is no longer responsible for that area.

That does not mean the original decision was wrong.

Instead, ReTrace can treat it as information that may need additional verification if new evidence appears.

Conceptually:

Old decision
↓
Original owner
↓
Owner still responsible?
│
┌─┴─┐
YES NO
│ │
│ ↓
│ Monitor
│ for new
│ evidence
│
Continue using
historical context

This is an important distinction.

The system should not say:

"The old fix is wrong."

It should say:

"The old fix has historical evidence, but new evidence may require verification."

When Old Problems Come Back

Now imagine a new complaint appears:

"Payment screen gets stuck again."

ReTrace can connect it with the historical information:

NEW COMPLAINT
↓
Similar historical issue
↓
Previous fix found
↓
Previous owner found
↓
Ownership changed
↓
New evidence detected
↓
Potential regression

The product team could then see something like:

⚠️ HISTORICAL ISSUE MATCH

Current issue:
Payment screen gets stuck

Related issue:
BUG-102

Previous resolution:
v1.4

Previous owner:
Priya

Current ownership:
Changed

New matching feedback:
3 reports

Suggested action:
Re-verify the previous fix

This is the Product Déjà Vu idea.

The Accountability Ledger

Another planned part of ReTrace is an Accountability Ledger.

Product teams make statements such as:

"Checkout performance has been fixed."

Instead of allowing that statement to disappear into documentation, we can preserve it as a historical claim.

For example:

CLAIM

Statement:
Checkout performance has been fixed.

Person:
Priya

Release:
v2.1

Date:
March 2026

Evidence:
QA testing

Later, ReTrace can compare the claim with new information.

For example:

Claim:
Checkout performance improved

Supporting evidence:
Checkout complaints decreased

New evidence:
Payment failures increased

The system should not automatically decide that the original claim was false.

Instead, it can highlight the conflicting evidence:

Previous product claim may require re-verification.

This makes the system useful for historical investigation rather than simply generating alerts.

Feedback Debt

Another idea in the project is Feedback Debt.

Some customer problems remain unresolved for a long time.

For example:

Month 1 → 12 complaints
Month 2 → 27 complaints
Month 3 → 41 complaints
Month 4 → 63 complaints
Month 5 → 91 complaints

A normal dashboard might simply display:

91 complaints.

ReTrace can provide more context:

Issue:
Checkout freeze

Age:
5 months

Mentions:
234

Status:
Unresolved

Owner:
Unclear

We can also create an estimated impact score.

For example:

Estimated support impact
+

Estimated customer impact

Estimated Feedback Debt

These numbers should be clearly labelled as estimates, not actual financial losses.

The purpose is to help a product team understand how an unresolved issue is accumulating over time

Architecture

What Makes ReTrace Different?

The original idea was simple:

AI that remembers customer feedback.

The direction I am taking it now is broader:

AI that remembers customer feedback together with the product history around it.

That means remembering:

What happened?
↓
When did it happen?
↓
What problem was reported?
↓
What was changed?
↓
Who worked on it?
↓
What did the team believe?
↓
What happened afterward?

The goal is to turn these disconnected records into usable organizational memory.

What I Learned

One of the biggest things I learned while working on this idea is that adding an LLM is not enough.

If the AI only sees the current conversation, it has very little historical context.

The interesting part begins when the system can connect:

Past
↓
Present
↓
People
↓
Decisions
↓
Evidence

I also learned that memory should not simply mean "store everything."

A useful memory system needs to answer:

What information is relevant right now?

This is why the combination of retaining, recalling, and reflecting is important for this project.

What I Want to Build Next

The next steps for ReTrace are to make the memory system more useful for real product workflows.

Some areas I want to explore are:

better historical feedback matching
stronger ownership tracking
product release timelines
automatic detection of repeated issues
evidence-based confidence updates
feedback-debt calculations
a conversational interface for querying product history

For example, eventually a product manager could ask:

"Have we had this problem before?"

And ReTrace could answer with:

Yes.

Similar issue:
BUG-102

First reported:
March 2025

Previous fix:
v1.4

Original owner:
Priya

Related recent feedback:
3 reports

Status:
Requires re-verification

That is the kind of product memory I want to build.

Conclusion

ReTrace started from a simple question:

What if an AI could remember what users complained about?

That question became something bigger:

What if an AI could remember what happened to a product, why decisions were made, who was responsible, and what happened afterward?

With Hindsight providing the long-term memory layer, ReTrace is designed to connect customer feedback with the history surrounding it.

The goal is not simply to store more information.

The goal is to make forgotten product history useful again.

ReTrace doesn't just remember what happened. It connects what happened before with what is happening now.

DEV Community: BAVUGARI CHARAN KUMAR

I Built an Agent That Remembers What Users Complained About

Estimated customer impact

Learn More