DEV Community

Harini Kasanagottu
Harini Kasanagottu

Posted on

RecallMeet - Personal AI Meeting Memory and Preparation Agent

Engineers attend dozens of meetings each month: sprint kickoffs, architecture alignments, and client syncs. Typically, automated tools produce isolated summaries that get lost in notes, forcing teams to restart from context each time a new meeting begins.

I built RecallMeet to solve this continuity problem. RecallMeet is a private, project-aware meeting memory system that connects past discussions, commitments, unresolved issues, and explicit feedback into progressively sharper pre-meeting briefings. Rather than acting as a passive transcript store, RecallMeet turns meeting context into an active agent memory loop.

The Problem

Ordinary meeting summarization is fundamentally stateless. Summarizers capture what occurred in a single conversation, but cannot prepare you for what happens next. Effective preparation requires cross-meeting continuity:

  • Tracking commitments by owner and due date.
  • Preserving unresolved technical and business blockers across syncs.
  • Remembering recurring client concerns that remain unaddressed.
  • Incorporating past human feedback so the system avoids repeating omissions.

Engineers do not need transcript dumps; they need briefings highlighting immediate priorities. If an assistant repeatedly overlooks client budget anxieties despite prior corrections, it fails as an intelligent partner. Meeting assistance requires memory that learns from human feedback.

How RecallMeet Works

RecallMeet addresses this problem through a closed loop:

Remember → Prepare → Feedback → Learn → Prepare Better

  1. Remember: When transcripts are uploaded, RecallMeet analyzes dialogue with Groq (openai/gpt-oss-120b), extracting commitments, decisions, and unresolved issues into PostgreSQL.
  2. Prepare: Before an upcoming sync, "Prepare Me" synthesizes a briefing using recent meetings, active commitments, and contextual memory recalled from Vectorize agent memory via Hindsight.
  3. Feedback: The user reviews the briefing and submits feedback on what was useful, what was missing, and what to prioritize next time.
  4. Learn: RecallMeet stores feedback in PostgreSQL and retains the qualitative guidance in the user's isolated Hindsight memory bank.
  5. Prepare Better: On subsequent requests, Hindsight recalls prior critiques, prompting the LLM to prioritize previously overlooked details.

RecallMeet dashboard showing active projects, recorded meetings, pending commitments, and Hindsight memory statusFigure 1: The RecallMeet dashboard displaying active project tracking, recent meeting intelligence, commitments ledger, and active Hindsight memory loop.

Architecture

RecallMeet separates deterministic relational state from associative long-term memory:

Frontend

Built with Next.js 14 (App Router), TypeScript, and Tailwind CSS. It handles project navigation, transcripts, commitments (pending, in_progress, completed), and briefing generation. The client (frontend/lib/api.ts) communicates via JWT tokens in localStorage.

Backend

Implemented with FastAPI and Python 3.13. Routers under app/api/ (auth, projects, meetings, commitments, preparation, feedback) enforce Pydantic validation and HTTPBearer authentication, scoping data access to the authenticated user.

Structured Storage

PostgreSQL serves as relational storage via SQLAlchemy 2.0 across six models (User, Project, Meeting, Participant, Commitment, PrepFeedback). Cascade foreign keys enforce referential integrity. PostgreSQL handles deterministic sorting by due date, project filtering, and feedback persistence.

LLM

Groq provides fast inference running openai/gpt-oss-120b for:

  1. Transcript Analysis (app/services/llm_service.py): Low-temperature JSON extraction of summaries, decisions, issues, and commitments.
  2. Preparation Generation (app/services/preparation_service.py): Synthesizes relational state and recalled memory into a seven-section executive briefing.

Long-Term Memory

Hindsight provides persistent semantic memory. PostgreSQL manages relational state, while Hindsight manages associative recall of qualitative context and past user critiques across sessions.

Hindsight Integration

Relational databases are well suited to structured queries, but they are not designed for associative semantic retrieval across past human critiques. Storing feedback as text columns in PostgreSQL preserves an audit trail, but relational queries cannot dynamically retrieve qualitative guidance relevant to an upcoming meeting.

Hindsight provides this capability through user-scoped memory banks. Memory is isolated per user using the authenticated user's ID, ensuring private observations never leak across accounts:

def get_user_bank_id(user_id: UUID | str) -> str:
    """Creates a stable Hindsight memory bank for one RecallMeet user."""
    return f"recallmeet:user:{user_id}"

def store_project_memory(user_id: UUID | str, content: str, context: str = "RecallMeet project memory"):
    client = get_hindsight_client()
    try:
        return client.retain(
            bank_id=get_user_bank_id(user_id),
            content=content,
            context=context
        )
    finally:
        client.close()
Enter fullscreen mode Exit fullscreen mode

When a user submits preparation feedback, app/api/feedback.py records the entry in PostgreSQL and formats a structured memory document containing the rating, useful aspects, missing details, and next-time focus. It calls store_project_memory() to commit this critique into Hindsight.

When generating future briefings, app/services/preparation_service.py issues a recall query following the Hindsight documentation. The recalled memories are injected directly into the LLM context under Long-term project memory from Hindsight:. The prompt explicitly instructs the model to prioritize items previously identified as missing, closing the learning loop.

Apollo Prepare Me briefing showing meeting context, commitments, unresolved issues, client concerns, and recommended focusFigure 2: The Prepare Me interface for Project Apollo showing past meeting history, active commitments, unresolved issues, and Hindsight memory synthesis.

Before and After: The Apollo Project

To verify this learning loop under realistic conditions, I tested RecallMeet on the Apollo project demonstration. The scenario centered on an initial sync titled "Apollo API Integration Kickoff", attended by Harini (Project Lead), Alex (Backend Engineer), and Sarah (Engineering).

Groq extracted the following items:

  • Alex will send complete API documentation to the client by Friday.
  • Target the first week of October for client rollout if authentication testing goes smoothly.
  • Harini will follow up with the client regarding budget constraints and final rollout timeline.
  • Authentication testing still needs to be completed.
  • The client has not confirmed whether the current scope fits their budget.

Run 1: Baseline Preparation (Before Feedback)

When I triggered "Prepare Me" before feedback existed in Hindsight, the engine generated a baseline briefing from meeting history and commitments:

  • Decisions & Commitments: Highlighted Alex's Friday documentation deliverable and target October rollout.
  • Open Issues: Emphasized technical blockers, specifically incomplete authentication testing.
  • Recommended Focus: Centered on engineering deliverables: completing authentication testing and delivering API docs.

While accurate, the baseline briefing had a clear blind spot: it prioritized technical tasks and gave minimal attention to client budget and scope uncertainty.

The Feedback Step

Using the feedback modal, I submitted a targeted correction:

  • What Was Missing: The briefing underplayed client budget constraints and whether current scope fits their budget.
  • Focus Next Time: Prioritize unresolved client concerns—specifically budget constraints, scope alignment, and confirming the rollout timeline.

RecallMeet saved the record in PostgreSQL and retained the critique in Hindsight bank recallmeet:user:{user_id}.

Run 2: Adapted Preparation (After Feedback)

I then generated a second preparation briefing. With feedback retained in Hindsight, the prompt retrieved the prior critique and adjusted its synthesis:

  • Client Concerns: Elevated to a primary section: "The client has not confirmed whether the current scope fits their budget. Clarifying budget constraints is critical."
  • Questions to Ask: Shifted from technical queries to client alignment: "Has the client confirmed the budget for the current scope? What scope adjustments are needed? Can we confirm the final rollout timeline?"
  • Recommended Focus: Reframed the objective: "Prioritize client alignment on budget and scope fit before locking in the October rollout, while confirming Alex's API documentation delivery."

The second briefing directly addressed what was previously missed without modifying prompt templates or database schemas.

What I Learned

Building RecallMeet reinforced four practical architectural lessons:

  1. Transactional state and semantic memory solve different problems: PostgreSQL ensures relational consistency, user ownership, and commitment status transitions (pending, completed). Hindsight provides an expressive memory layer that connects human critiques to future generations without schema churn.
  2. User-scoped memory banks enforce strict privacy boundaries: In multi-user systems, shared memory models create data-leak risks. Deriving bank IDs strictly from the authenticated user (recallmeet:user:{user_id}) helps ensure that users never share memory banks even on similarly named projects.
  3. Cold-start memory access requires defensive handling: Querying an uninitialized Hindsight bank before feedback is retained can return a 404. Implementing graceful fallback handling in recall_project_memory (commit 42c4453) ensures new users receive baseline briefings without errors.
  4. Feedback is wasted unless it modifies future agent behavior: Most products isolate user ratings in analytics dashboards. By converting evaluations into persistent agent memory, RecallMeet turns human corrections into direct behavioral adaptations.

See RecallMeet in Action

Watch the complete demo of RecallMeet:

https://youtu.be/xuQOZrfyWJU

The complete source code is available on GitHub:

https://github.com/Ho436-art/RecallMeet

Conclusion

Meeting assistants should not merely document past conversations; they should help teams navigate upcoming ones. When tools lack persistent memory, users repeatedly correct the same omissions across project cycles.

By combining PostgreSQL for structured relational guarantees with Hindsight for persistent agent memory, RecallMeet transforms meeting syncs and human critiques into an adaptive asset. Meeting intelligence becomes genuinely useful when it remembers corrections and improves what it does next.

Top comments (0)