Recall AI for Graph Hacks 2026

Aman Kumar — Sun, 18 Oct 2026 10:13:47 +0000

Building RecallAI in 4 Days: What We Tried, What Went Wrong, and What We Learned

Have you ever explained something to an AI chatbot, returned to it a few days later, and had to explain everything all over again?

That was one of the problems we wanted to explore with RecallAI: an AI tutor that can remember useful information from previous conversations and use it to give more personalized responses.

I'm Aman Kumar, and along with my friends Rishu,Abhishek and Ayan, I worked on RecallAI for Graph Hacks: Context for AI Agents, a hackathon organized by WeMakeDevs and FalkorDB. We chose Track 02, Agent Memory and Coordination, because we wanted to understand how persistent memory could make AI applications more useful.

We had four days, limited experience with some of the technologies, and plenty of things to figure out. We didn't enter expecting to build a perfect AI system. We wanted to try something challenging, learn how different parts of an AI application work together, and see how far we could get.

Here's how those four days went.

Before We Started: Working With Limited Resources

One of our biggest challenges was our available hardware.

We had only one reasonably capable laptop for running demanding local workloads. That meant we couldn't simply run every component locally and experiment freely. We had to work around our hardware limitations, with some of our work relying on cloud resources instead.

This also affected how we approached the language model. Running and experimenting with LLMs can require considerable computing resources, especially when working with models that are difficult to run on ordinary laptops. We had to be realistic about what we could run, what we could test, and how much time we could spend experimenting.

We were also learning several things at once: how language models work, how to connect a backend to a database, how to manage conversation history, and how to make the frontend communicate with everything behind it.

In other words, we weren't just building an application. We were learning the technologies while trying to make them work together.

These limitations influenced our decisions throughout the hackathon. Instead of training a language model from scratch, we decided to work with an existing model and focus our effort on building the memory system around it.

Day 1: Figuring Out the Architecture

Before writing much code, we needed to understand what we were actually trying to build.

A basic chatbot receives a message, sends it to a language model, and returns a response. But we wanted RecallAI to do something more: use relevant information from previous conversations, even when those conversations happened in different sessions.

For example, imagine a student tells an AI tutor that they understand Python loops but struggle with dictionaries. A few days later, they ask for help preparing for a programming exam.

Ideally, the AI shouldn't need the student to repeat everything. It should be able to retrieve the relevant information and use it to tailor its explanation.

That meant we needed more than a chat interface.

Our architecture included four main components:

Frontend: The interface where users can chat with the AI and interact with the application.
Backend: The part responsible for processing requests, connecting the components, and coordinating memory retrieval.
Language model: The component that understands questions and generates responses.
FalkorDB: The graph database we chose to store and retrieve relationships between pieces of information.

We decided to use FalkorDB because we wanted to explore graph-based memory rather than treating every conversation as an isolated block of text.

However, deciding on an architecture and getting all its components to communicate properly turned out to be two very different things.

Day 1 takeaway:

«"Having a clear idea of what you want to build is one thing. Figuring out how all the pieces work together is another."»

Day 2: Understanding LLMs and Graph Memory

On the second day, we focused more on how the language model and memory system would work together.

One important thing we learned was that a language model doesn't automatically gain reliable, permanent memory just because we continue chatting with it. The information available to it depends on the context we provide, along with the capabilities of the model and application.

We also had to distinguish between training a model and giving an application persistent memory.

Fine-tuning changes a model's behavior by training it on examples. Persistent memory, on the other hand, allows an application to store information externally and retrieve it when needed. These solve different problems.

Given our hardware limitations and the time available, training a model from scratch wasn't realistic. Instead, we decided to use Qwen2.5-1.5B-Instruct, a relatively small, instruction-tuned language model.

We chose this model as a practical starting point for experimenting with LLM-powered responses while working within our resource constraints. Its relatively small size made it a more realistic option for our project than attempting to work with a much larger model.

Our focus wasn't on building a new language model from scratch. It was on understanding how an existing model could work alongside a persistent memory system to deliver more personalized responses.

Then there was the graph database.

A graph can represent information as connected entities and relationships. For example, a student could be connected to a topic they struggle with, a previous study session, or a concept they have already learned.

This gives us a way to represent relationships between pieces of information instead of simply saving a long conversation and hoping the model can make sense of it later.

But we soon realized that storing information is only one part of memory. The application also needs to find the right information when a new question arrives and make that information available to the model.

We were beginning to understand the design. Getting the behavior right was another challenge.

Day 2 takeaway:

«"A database can store information, but that doesn't mean the AI automatically knows when or how to use it."»

Day 3: When Memory Didn't Work as Expected

This was one of the most important parts of the project.

We connected the components and began testing whether RecallAI could use information from previous conversations. At first, it seemed promising. The system could sometimes recognize specific keywords or recall information when we referred to it directly.

But when we asked questions that depended on broader conversational context, the results were inconsistent.

Sometimes the AI behaved as if it had no memory. Other times, it produced an answer that sounded confident but didn't accurately reflect the previous conversation.

For example, remembering a specific phrase from an earlier chat is not the same as understanding the broader context around it. A system might retrieve a keyword successfully but still fail to connect that information to the user's current question.

We had to consider several possible reasons:

Was the information actually being saved correctly?
Were we retrieving the right information from FalkorDB?
Was the backend passing the retrieved information to the language model?
Was the model receiving enough context to understand the connection?
Was the model ignoring or misinterpreting the information it received?

These are different stages of the same process, and a problem at any one of them can make the entire memory system appear broken.

We couldn't confidently identify and resolve every cause during the hackathon. That was frustrating, but it taught us an important lesson: a successful database connection does not automatically mean that an AI application has reliable memory.

We needed to test the complete process, from saving a memory to retrieving it in a new session and checking whether the model actually used it.

Day 3 takeaway:

«"Remembering a keyword isn't the same as remembering the conversation. And retrieving information isn't the same as understanding it."»

Day 4: Prioritizing What Actually Matters

By the fourth day, it was tempting to think about adding more features.

We could imagine a study planner, automatic practice questions, progress tracking, or even multiple AI agents working together. These features might eventually make RecallAI a more useful study companion.

But adding more features wouldn't solve the problem we were still facing.

If the system couldn't reliably remember and use previous conversations, building more functionality on top of it would only make the application more complicated.

So we focused on the core idea behind RecallAI: memory that is useful, relevant, and available when the user needs it.

For that to work properly, we needed to get several things right:

Save useful information: Store relevant details from conversations rather than relying entirely on the current chat.
Retrieve the right memories: Find information related to the user's new question, even when the wording is different.
Pass the information to the model: Make the retrieved context available when generating a response.
Use the context correctly: Ensure that the response actually reflects the relevant information instead of generating an unrelated answer.
Avoid irrelevant memories: Don't bring up unrelated information when answering a new question.
Keep users' memories separate: Ensure that one user's stored information isn't accidentally used in another user's conversation.

These were the behaviors we wanted to build toward. We didn't manage to perfect all of them in four days, but identifying the gap between our goal and the actual behavior helped us understand what needed attention next.

Day 4 takeaway:

«"Building more features doesn't help if the core feature isn't reliable yet."»

What We Learned

Looking back, the biggest lesson wasn't about a particular framework, model, or database.

It was about understanding how an AI application works as a complete system.

Before this project, it was easy to think that connecting a language model to a database would be enough to give it memory. We learned that the real challenge is coordinating the entire process: storing information, finding the right information later, passing it to the model, and ensuring the model uses it appropriately.

We also learned to work within our constraints. With limited hardware, a short deadline, and several technologies to learn, we had to make practical decisions rather than attempt everything at once.

Choosing Qwen2.5-1.5B-Instruct was part of that approach. Rather than spending our limited time trying to run a much larger model, we could focus on the memory architecture and how the different components interacted.

We also learned that a smaller model doesn't automatically make an AI application simpler to build. The model still needs appropriate context, and the application still needs a reliable way to retrieve and supply relevant information.

And perhaps most importantly, we learned that a feature isn't finished just because the individual components are connected. It needs to work reliably from the user's perspective.

A database can be connected. A model can generate responses. A frontend can look complete. Yet the experience can still fail if the information doesn't flow correctly between them.

That is something we want to keep in mind as we continue building.

What's Next for RecallAI?

Our long-term goal is to turn RecallAI into a more personalized AI study companion.

Imagine an assistant that remembers which concepts you struggle with, recognizes when you repeatedly make the same mistake, and adapts its explanations based on your learning history.

Rather than starting from zero every time, it could gradually build a better understanding of what you know, what you need help with, and how you prefer to learn.

But before we can get there, we need to make the fundamental memory system more reliable.

Our next steps are to test memory storage and retrieval more systematically, understand why broader context is sometimes lost, and verify that retrieved information is actually being passed to and used by the language model. We also need to test how the system behaves when no relevant memory exists.

These are the problems we want to solve before adding more features.

Final Thoughts

Building RecallAI in four days wasn't a story of building a perfect AI product. It was a process of trying things, running into problems, learning how the different pieces fit together, and discovering how much more there was to understand.

We started with a simple idea: an AI tutor should not have to forget everything useful about a student between conversations.

We haven't completely solved that problem yet. But we now have a much clearer idea of what it takes to work toward a solution.

Real memory isn't just about storing information. It's about connecting the right information to the right question at the right time.

That's the problem we're continuing to work on with RecallAI.

About the Author

Aman Kumar is a B.Tech CSE (AI/ML) student at Amity University Patna, interested in artificial intelligence, machine learning, large language models, and building practical technology. He is currently working on RecallAI with his friends Rishu,Abhishek and Ayan for Graph Hacks 2026.

DEV Community: Aman Kumar

Recall AI for Graph Hacks 2026