Memory Lab: Can an AI Broker Remember What Clients Really Want?
Built for the Hindsight Hackathon, with persistent agent memory.
A client tells a property broker: "3BHK, Velachery, ₹15,000."
The broker shows four flats. The client rejects all four. 🏠
Here's the funny part: none of the rejections were about budget or location.
❌ "No parking."
❌ "Not north/east facing."
❌ "The road is too narrow."
It's a scene almost every rental broker in Chennai will recognize. The client never said "parking" or "vaasthu" upfront. The real preference only appeared in the rejections.
And a broker doesn't have one client. A broker has 60. Nobody remembers every "no" from 60 people, so the same wrong flats get shown again and again. One deal can take 3 weeks and 12 site visits.
Property portals have filters, but filters only capture what customers say. They can't learn from what customers reject.
So for the Hindsight Hackathon, I asked a simple question: what if the agent just remembered? 😁
**
Kumar's Notebook
**
I built a small web app called Kumar's Notebook. Think of it as the smart notebook a good broker wishes they had.
After every site visit, the broker logs three things: which property was shown, how the client reacted, and why they rejected it.
The app has 10 sample listings in Velachery and Adyar, three clients, and a memory layer behind it. The important part: the agent never gets a "preferences" form. Everything it knows about a client comes from past visits.
How Hindsight memory is used
Hindsight gives the agent three operations, and each one maps to a step in the broker's day:
Hindsight In Kumar's Notebook
Retain Every visit is stored: property, client reaction, reject reason
Recall When a new listing comes up, the agent pulls that client's past visits
Reflect The agent compares the stated requirement with the pattern in the rejections
I wrapped memory in a tiny adapter so the UI doesn't care where memory lives:
[NOTE TO SELF: explain here how your build actually connects to Hindsight (server, API key, or local fallback) and keep it honest.]
The reflect rule is intentionally simple: one rejection is noise, two rejections with the same reason is a pattern.
The test scenarios
Like any good lab, I wanted to see how the agent behaves in different situations. I prepared four scenarios.
1. Cold start (Arun Prakash)
Arun wants a 3BHK in Velachery under ₹16,000. He has no visit history.
The agent has nothing to learn from, so it does the only honest thing: it shows every listing that matches the stated filters. That's 6 listings, the same as any portal.
2. Hidden priorities (Suresh Kumar)
Suresh asks for a 3BHK in Velachery under ₹15,000 and rejects four flats. After four rejections, memory looks like this:
No parking: 3 of 4
Not north/east facing: 3 of 4
Narrow road: 1 of 4
Parking and facing both crossed the threshold. The narrow road didn't, because it only came up once. The agent now tells the broker that Suresh's real priorities are parking and north/east facing, and shows 2 listings instead of 6.
3. A different pattern (Priya Raman)
Priya has a budget of ₹20,000 and keeps rejecting flats well under it. Both of her rejections are for ground floor. She never said it, but memory did.
Same agent, same code, completely different hidden preference. Of her 4 portal matches, the agent narrows it down to 2.
*4. How fast does it learn?
*
This one surprised me a little. Because the rule only needs a reason to repeat twice, the agent doesn't have to wait for four rejections.
Replaying Suresh's visits one at a time:
After visit 1: no pattern yet, so the agent still shows all 5 unvisited flats
After visit 2: parking and facing both repeat, and the list drops to 2 listings
The agent found the pattern after just two rejections.
Results
Scenario Portal-style filters With memory What the agent learned
Arun (no history) 6 6 Nothing yet, so no filtering
Suresh (4 rejections) 6 2 Parking + north/east facing
Priya (2 rejections) 4 2 Not ground floor
Suresh after only 2 rejections 6 2 Parking + north/east facing
What I found interesting
First, memory only helps once there is something to remember. Arun's result is the same as a portal's, and I like that. The agent doesn't pretend to know a client it has never met.
Second, the signal was never in what clients said. Suresh's budget and area were fine. Everything useful sat in the reasons behind his "no".
Third, a tiny rule goes a long way. I expected to need something fancy to reflect on patterns. Counting repeated reasons was enough for this problem, and it has a bonus: the broker can understand exactly why the agent made a suggestion.
Honest limitations
This is a hackathon prototype, not a benchmark:
The demo uses 10 hand-made listings and a few hand-made visits.
The results above come from that demo data, not from real brokers or real clients.
"12 site visits per deal down to 4" is my goal, not a measured result. What I can show today is narrowing the list, for example from 6 listings to 2.
Reject reasons are picked from a fixed list. Real clients say messier things.
What's next
Voice notes: "rejected, no parking" and memory updates automatically
WhatsApp import, since that's where brokers really keep their notes
Weighting recent rejections more heavily
A pilot with a real broker to measure actual site visits per deal
Summary
Portals give you filters. What a broker needs is memory: something that remembers every "no" and learns what the client really wants.
What surprised me most wasn't that the agent could learn a pattern. It was how little it took: two rejections with the same reason were enough to change what the agent suggests next.
If you're a broker, or you're building agents with memory, I'd love to hear what you'd test next. 🙌



