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.
Top comments (0)