Inspiration We built MindChat around a common failure mode in both human memory and traditional search: people often do not remember exact words but they do remember fragments, concepts, numbers, scenes and associations. That is the tip-of-the-tongue problem. We wanted to build a system that feels closer to how memory actually works, using recent conversation as working memory and a knowledge graph as long-term memory.
What it does MindChat helps users recover ideas they cannot name directly. Instead of relying on exact keyword matching, it stores conversations as concepts, topics and relationships. Users can later ask vague questions like “that thing about memory and 7,” and MindChat uses semantic retrieval cues to trace back the likely answer. It also visualizes how ideas are connected through a live memory map.
How we built it We built MindChat with a FastAPI backend and a React frontend. OpenAI powers the conversational layer and lightweight concept extraction, acting as working memory over a sliding recent-message window. Neo4j AuraDB stores messages, concepts, topics and transitions as a long-term memory graph. Tavily adds research support for questions that need outside information. On the frontend, we designed a chat workspace paired with a memory map so users can see both the active conversation and the stored conceptual structure behind it.
Challenges we ran into The biggest challenge was making the system feel meaningfully different from a normal chatbot. It was easy to get a chat response working but harder to make vague recall, memory consolidation and graph retrieval actually feel useful. We also ran into integration issues around environment setup, backend restarts, Neo4j connectivity, OpenAI quota limits, and keeping the frontend aligned with a changing backend structure during rapid iteration.
Accomplishments that we're proud of We are proud that MindChat goes beyond basic chat and implements a real memory architecture. We built a working pipeline where conversations are stored in Neo4j, periodically consolidated into a graph and retrieved through semantic cues rather than exact text search. We also created a UI that makes the system understandable in a demo: a conversation panel on one side and a live memory map on the other.
What we learned We learned that building with multiple systems is not just about connecting APIs, but about defining clear roles for each part of the stack. We also learned that memory-inspired product design requires stronger UX framing than normal chat applications, because users need to understand why vague input should work. On the engineering side, we learned a lot about graph modeling, fallback design and how to keep a hackathon codebase moving without losing the core product story.
What's next for MindChat Next, we want to make MindChat more personalized, more reliable over longer conversations, and more natural to use in everyday life. That includes improving the quality of the memory graph, strengthening retrieval ranking for vague queries, and building richer multimodal memory cues so users can recover ideas from fragments, scenes, tone, and context, not just text. We also see strong potential in adding a voice-first layer using Modulate AI, so users could speak naturally to MindChat and use voice as another memory trigger, making recall feel more intuitive and human. Beyond that, we want to deploy MindChat end-to-end, test it with real users, and evolve it from a hackathon prototype into a genuine memory-assistance product.
Built With
- and
- answers
- api
- as
- auradb
- backend
- build
- chat
- concept
- database
- deployment
- development
- extraction
- fastapi
- for
- frontend
- graph
- html/css
- intended
- interface
- javascript
- long-term
- mcp
- memory
- neo4j
- openai
- python
- react
- research-enhanced
- responses
- semantic
- server
- styling
- tavily
- the
- tooling
- ui
- vite
Log in or sign up for Devpost to join the conversation.