One thing that bothered me while working with AI support agents was how easily they forget what happened before.
A customer can explain a problem, get a solution, confirm that it worked, and then come back later with the same issue — and the whole conversation can start from zero again.
So I built RecallIQ.
The idea behind it is pretty simple: if a solution worked for a customer before, the agent should be able to remember it.
RecallIQ is an AI customer support agent built using Hindsight, Groq and Flask. The frontend is built with HTML, CSS and JavaScript, and the application is deployed on Render.
The main workflow is:
Recall → Understand → Resolve → Verify → Remember
The interesting part for me was making memory an actual part of the support flow rather than just adding a memory feature somewhere in the background.
How it works
When a customer starts a support conversation, RecallIQ first looks for relevant information from their previous interactions using Hindsight.
For example, a customer might have previously had a duplicate billing issue.
The stored context could look something like:
Issue: Duplicate billing charge
Cause: Payment retry after a gateway timeout
Resolution: Duplicate charge refunded
Later, if the same customer reports a similar billing problem, RecallIQ can retrieve that previous context before generating the response.
Without that memory, the agent might simply ask:
“Can you provide more details about your billing issue?”
With the recalled context, it can understand that the customer has already experienced a similar problem and that a particular resolution worked previously.
That difference is what I wanted to demonstrate with RecallIQ.
But I didn't want it to remember everything.
This was another important part of the design.
Just because an AI suggests something doesn't mean the solution actually worked.
So RecallIQ has a verification step.
After the agent provides a solution, the customer can confirm that it worked.
Only then do we treat the resolution as something worth retaining.
So the flow becomes:
Customer problem
↓
Recall previous context
↓
Generate solution
↓
Customer confirms
↓
Remember confirmed solution
This makes the memory more useful for future conversations.
Building the memory layer
Hindsight is the part that makes the persistent memory workflow possible.
Instead of treating every customer message as an isolated request, RecallIQ can retrieve information from previous interactions and use it when handling the current one.
The rest of the application is intentionally straightforward:
Frontend
↓
Flask Backend
↓
Groq
↕
Hindsight
The frontend handles the support experience, Flask connects the different parts of the application, Groq handles the language generation, and Hindsight provides the memory layer.
What I found interesting
The biggest thing I learned while building this is that memory by itself isn't the interesting part.
The interesting part is deciding when memory should affect the next response.
If an agent remembers irrelevant information, memory doesn't help much.
But if it remembers something directly related to the customer's current problem — especially a solution that was already confirmed to work — that context can change the interaction.
That's why I focused RecallIQ on one specific workflow instead of trying to build a huge customer-support platform.
What I would improve next
There are still quite a few things I would improve before treating this as a production system.
I'd like to make customer identity and session handling more robust, improve memory retrieval and filtering, add stronger human-agent escalation, and evaluate how consistently the system retrieves the right previous context.
But the core idea is working:
A support agent can recall what happened before, use that information to handle the current problem, verify the solution, and retain what actually worked.
That's the part of RecallIQ I'm most interested in exploring further.
Project: https://github.com/devsharonn/recalliq
Hindsight: https://github.com/vectorize-io/hindsight
Top comments (0)