With over 5 years in customer support and retention, I've lost count of how many times I've seen the same pattern: a customer explains an issue, gets it "resolved," and then has to explain the same problem again weeks later, as if the first conversation never happened. Support systems forget. Customers don't.
That frustration, seen over years on the support side, is what led me to this hackathon project.
Most support systems and most AI chatbots treat every interaction as isolated. They don't remember. So patterns that should be obvious (repeated complaints, dropping usage, unresolved issues) never get connected until a customer just leaves.
That became the seed for my project: the Retention Risk Agent.
The Problem With "Forgetful" AI
Most AI tools answer questions in the moment, then forget everything. Ask a chatbot about a customer's history, and it only knows what's in that single message, not what happened last week, last month, or across five different support tickets.
For churn prediction, that's a fatal flaw. Churn isn't a single event. It's a pattern, a series of small signals that only make sense when viewed together over time. This is something I understand deeply from years of watching it happen firsthand.
Cognee is an open-source memory layer for AI agents. Instead of treating each interaction as isolated, it builds a knowledge graph, connecting facts, relationships, and context across everything you feed it. That's exactly what churn detection needed.
What I Built
I created a Python script that:
Ingests customer records (support tickets, usage patterns, plan changes)
Uses Cognee to build a memory graph connecting these signals
Asks a simple question: "Which customers show signs of churn risk, and why?"
The result wasn't a keyword match; it was reasoning. The agent correctly flagged a customer whose usage dropped 80% and who'd ignored two check-in emails. It flagged another who'd complained twice about slow support and mentioned a competitor. And critically, it correctly ignored healthy, engaged customers; it wasn't just flagging everyone; it was actually connecting patterns.
My Path Into This
I started learning to build with AI tools around mid-2025, coming from a customer support and retention background rather than a traditional coding one. I'm not a formally trained developer, but over the past year I've been steadily learning by building real projects with AI-assisted development, using tools like Claude to guide the technical implementation while I bring the domain understanding.
This project is the clearest example yet of that combination working: years of understanding why customers churn, paired with new technical ability to actually build something that detects it.
What I Learned
Memory is the missing piece in most AI applications people build today. Without it, every interaction starts from zero. With it, the same AI model can reason across time, spot patterns, and give context-aware answers that isolated queries never could.
I also learned that persistence matters, technically and personally. I hit rate limits, misconfigured environment files, and typos more times than I can count. Each one felt like a wall until it wasn't.
Check It out!
The full code is on GitHub: https://github.com/Simbyheart/Retention-Risk-Agent
Live demo on Replit: https://replit.com/@EmmyB/Python-Script-Runner
Built for the Cognee "Where's My Context?" hackathon, because agents shouldn't forget the people they're supposed to help.
Top comments (6)
This is the pattern I keep telling people about, demonstrated perfectly: your five years in customer support aren't the thing you're overcoming to become a builder — they're the reason your agent knows which signals actually matter. A pure engineer could wire up Cognee in an afternoon and still not know that an ignored check-in after a usage drop means something. You did. I came into building from an equally non-technical field, and the tools I've shipped that people actually use all came from that same place: knowing the domain first, learning the tech second. One question — when the agent flags someone, what happens next? The handoff from "the system noticed" to "a human acts on it" is where these things live or die, and your support background probably gives you strong opinions there.
Thank you for this, genuinely one of the most thoughtful comments I've gotten, and you've articulated something I felt but hadn't put into words: knowing the domain first, learning the tech second.
On the handoff question, you're right that this is where it lives or dies. Right now, the agent just flags and explains, but based on what I saw in support, the handoff needs to preserve why, not just that. A generic "this customer is at risk" alert gets ignored by week two. But "this customer complained twice about the same unresolved issue and mentioned a competitor" gives whoever picks it up an actual starting point; they know what to say before they even open the ticket.
If I extended this, my instinct would be to route the flag straight to whoever owns that customer relationship, with the reasoning attached, not just a score. The worst version of this system is one that adds another dashboard nobody checks. The support side of me is skeptical of anything that creates work without removing more work than it creates.
Would love to hear how you've seen that handoff problem solved (or not solved) in what you've shipped.
"Preserve why, not just that" is the cleanest framing of this I've seen — and your two-week decay estimate for generic alerts matches my experience exactly.
Honest answer to your question: I've solved it once and failed at it once, and the difference wasn't intelligence, it was geography. The failure was a statistics screen I built early on — useful numbers, nobody opened it. It assumed people would come to the data. They never do. The one that worked delivers the flag as a direct message inside the intranet my coworkers already live in all day, addressed to the specific person who owns that patient or task, with the reason written in the message itself. Same information, different location, completely different outcome.
So my one hard-won rule matches your instinct: dashboards answer questions someone already has; handoffs have to arrive where the person already is. And your work-accounting test — remove more work than it creates — is exactly right. A good flag should replace the investigation, not start one. Your "they know what to say before opening the ticket" line is that test passing.
That geography insight is going to stick with me — "dashboards answer questions someone already has; handoffs have to arrive where the person already is" might be the most useful sentence I read this week. Genuinely rethinking the next version of this because of it.
Thanks for pushing this conversation somewhere real. Appreciate you.
That's the best possible outcome of a comment thread — take the sentence, it was half yours anyway; your "preserve why, not just that" is what it was answering. When the next version ships, post about it. I'd genuinely like to see where the routing lands, and I suspect I'm not the only one following along now.
Awww, Sure.
Thank you so much!