Most meeting tools help during a meeting, but the real challenge often starts before it. Users spend time searching for context, reviewing past interactions, and preparing discussion points.
While building MeetMind, our goal was to make meeting preparation and follow-up simpler and more intuitive. As a frontend developer, I focused on designing user-friendly interfaces, building responsive components, and creating a smooth workflow from meeting preparation to post-meeting insights.
In this article, I'll share the design decisions, frontend challenges, and lessons I learned while building the user experience behind MeetMind.
How We Used Hindsight Memory to Make Our AI Meeting Assistant Actually Remember Things
Hook
I've been in too many meetings where I blanked on something a client told me weeks ago. You're sitting there, nodding, and somewhere in the back of your head you know they mentioned a budget number or a deadline — but you can't pull it up. That feeling is expensive. It erodes trust, slows decisions, and makes you look unprepared.
That's the problem MeetMind was built to solve. And the hardest part of building it wasn't the AI — it was making the AI remember.
What Is MeetMind — And How Does It Actually Work?
MeetMind is a web application that functions as your AI-powered pre-meeting assistant. Here's the full user flow:
Before a meeting: Type a contact's name, click "Get Briefing." The app retrieves everything stored about that person — notes, promises, project details — passes it to the LLM, and returns a structured briefing: a summary of past interactions, key reminders, and conversation openers grounded in your actual history with them.
After a meeting: Type your notes and click "Save." The system stores them under that contact's name for next time.
Under the hood: Python + Flask backend, Llama 3.3 70B on Groq's inference API, and a JSON-backed memory layer modeled on the Hindsight architecture.
The interface is intentionally minimal. Two panels, two actions — "Generate my briefing" before the meeting, "Save to memory" after. The complexity lives in the backend, not the UI.
My Role
I built memory_vault.py — the module that stores and retrieves contact history — and wired it into the Flask routes in app.py. I also owned the prompt engineering in ai_brain.py: turning raw stored notes into something an LLM could synthesize into a reliable, structured briefing.
The question I kept running into: how do you give a stateless LLM meaningful past context without just dumping a wall of text at it?
The Core Technical Problem
Every call to Groq's API starts from zero. The model has no session state, no memory of past calls, no knowledge of your contacts. When you ask MeetMind for a briefing on "Rahul," the LLM literally does not know who Rahul is unless you tell it — right now, in this prompt.
This is the fundamental constraint of building stateful applications on stateless LLM APIs. You have to externalize memory, retrieve the right pieces at query time, and inject them into context in a form the model can actually use. If you get that pipeline wrong, your "AI assistant" is just generating plausible-sounding text with no grounding in reality — which is worse than useless for a meeting tool.
What We Tried First
The naive approach: save every interaction as a single text blob and pass the whole thing into the prompt every time.
It worked briefly. As history grew, token counts climbed and output quality dropped. The model fixated on old irrelevant details — a coffee preference from six months ago got as much attention as the current project deadline. Briefings became noisy and untrustworthy. We needed structure around what gets stored, how it's retrieved, and how it's formatted before the model sees it.
Why Hindsight Changed How We Thought About This
We studied Hindsight as a reference for how agent memory should be designed. The core concept, explained well at
Source code:
Vectorize agent memory: https://vectorize.io/what-is-agent-memory
SOCIAL SHARE CARD GENERATOR