How an AI meeting assistant solves the pre-meeting memory gap

Preparing for a meeting can feel like assembling a puzzle from scattered clues. You scroll through old emails, scan notes from last week’s call, and hope you don’t miss a critical detail. Meanwhile, your counterpart enters the room already briefed—because their assistant remembered everything.

That imbalance inspired the team behind MeetMind to rethink how AI can truly support real-world meetings—not just during them, but before and after. As a frontend developer focused on user experience, I spent months refining how the tool captures, stores, and retrieves context so users never walk into a discussion unprepared. Here’s what we learned.

Why most meeting tools miss the point

Most digital assistants shine in the moment: they transcribe speech, highlight action items, and summarize discussions. But the real friction happens long before the meeting starts. Users waste time digging through past interactions, refreshing their memory on who said what and when. A missed reference—like a budget figure or deadline—can erode trust and slow decisions.

MeetMind was designed to eliminate that friction. Instead of relying on manual searches, users can retrieve a concise briefing in seconds. The interface is intentionally simple: one button to generate a briefing before the meeting, another to save new notes afterward. The complexity lives not in the UI, but in how the system remembers—and forgets—relevant details.

How MeetMind turns scattered notes into a reliable briefing

The app’s workflow is straightforward:

• Before a meeting: Enter a contact’s name and click "Get Briefing." The system retrieves stored context—past notes, promises, project updates—and passes it to an LLM, which returns a structured summary tailored to the upcoming discussion.
• After a meeting: Add your notes and click "Save." The system stores them under the contact’s profile for future use.

Under the hood, MeetMind combines Python, Flask, and the Llama 3.3 70B model running on Groq’s inference API. The memory layer, built on a JSON store modeled after Hindsight’s architecture, acts as a bridge between raw notes and structured context. This ensures the LLM always receives relevant, concise information—no wall of text, no irrelevant old details.

The hidden challenge: teaching AI to remember the right things

Stateless LLM APIs, like Groq’s, start each session from scratch. When you ask MeetMind for a briefing on "Rahul," the model has no prior knowledge of who Rahul is—unless you explicitly provide that context in the prompt. This creates a paradox: an AI assistant that sounds intelligent but lacks grounding in real history is worse than no assistant at all.

Our first attempt was simple: save every interaction as a single text block and feed it to the model each time. It worked initially, but as history grew, so did token counts—and so did noise. The model fixated on outdated details, like a coffee preference from months ago, while missing critical deadlines. Briefings became unreliable, and users lost confidence.

To fix this, we needed structure. Memories shouldn’t be passive dumps; they should be active, queryable records with clear rules for what to keep and how to retrieve it. That’s where the Hindsight architecture came in.

Building memory with purpose: the Hindsight approach

The Hindsight framework reframes memory as a system with two core operations:

• retain: store a new memory
• recall: retrieve memories relevant to a specific query

This shift transforms memory from a storage problem into a design problem. Instead of asking, "Where do we store this note?", we ask, "What interface should we expose for writing and reading memories?" With that interface defined, the rest—backend storage, retrieval logic, prompt formatting—becomes modular and replaceable.

We implemented a lightweight version of this interface in MockHindsightClient. It uses a JSON store to simulate the full Hindsight SDK, allowing us to test retrieval logic before integrating semantic vector search. The goal: ensure every briefing starts with the right context, no more and no less.

Code deep dive: how memories are stored and retrieved

The backbone of MeetMind’s memory system is memory_vault.py, where new notes are parsed and stored. Here’s how it works:

# memory_vault.py
def retain(self, text):
    if "Meeting with " in text:
        content_split = text.split("Meeting with ")[1]
        parts = content_split.split(": ")
        if len(parts) >= 2:
            contact_name = parts[0].strip().lower()
            notes = ": ".join(parts[1:])
            if contact_name in self.storage:
                self.storage[contact_name].append(notes)
            else:
                self.storage[contact_name] = [notes]
            self._save()
            return True

This function takes a plain-language note like:

Meeting with Rahul: He confirmed Tailwind CSS and wants the project in 3 weeks.

It extracts the contact name (normalized to lowercase for consistency) and the full note body, even if the note contains colons—such as timestamps or URLs. After storing the note, it immediately persists changes to disk. While this slows writes, it prevents data loss from crashes.

What’s next for AI-powered meeting assistants

The biggest lesson from building MeetMind? Memory isn’t just about storage—it’s about retrieval. The best AI tools don’t just remember; they recall the right things at the right time. As LLMs grow more capable, the challenge will shift from parsing speech to curating context intelligently.

For users, that means fewer last-minute scrambles and more confident conversations. For developers, it means building systems that treat memory as a first-class feature—not an afterthought.

The future of meetings won’t belong to tools that transcribe well. It will belong to tools that prepare us well.