Meeting Intelligence & Founder Memory: A Copilot That Actually Knows the Business

The business problem

A founder juggling many clients loses context between calls: what was promised, what changed, what that client's numbers looked like last month. Off-the-shelf note-takers summarize a call after it ends, but they know nothing about your business, cannot help you during the conversation, and their notes go somewhere you will never look again. The real need is memory that compounds and help that arrives in the moment.

Constraints

• Real time or useless. A suggestion that arrives after the client moves on has zero value; the loop from speech to transcript to retrieval to suggestion has to run in seconds.
• Private by design. Client conversations and business records cannot live in a third-party notetaker's cloud; the knowledge base stays local.
• Trustworthy retrieval. Mid-call is the worst possible moment for a hallucination, so answers ground in retrieved documents from the founder's own corpus, not the model's imagination.

What I personally designed and built

The entire system, end to end and solo: a desktop application that captures call audio and transcribes it live; a private knowledge base of client files, meeting summaries, and company documents indexed with vector search; a retrieval loop that watches the conversation and surfaces relevant context and suggested answers in real time; a discreet teleprompter-style display for use during calls; screen-vision so the copilot also understands what is being presented; and post-call debriefs that write structured summaries and decisions back into the knowledge base, which the next call then retrieves from. That write-back loop is the point: the system gets smarter with every meeting.

Architecture and key decisions

• RAG over fine-tuning. Client facts change weekly; retrieval over a continuously updated index stays current where a fine-tuned model would fossilize.
• Local vector store. FAISS on-device keeps sensitive business context out of third-party clouds and keeps retrieval latency inside the real-time budget.
• Memory as files. Summaries and client records persist as plain, human-readable documents, so the founder can read, correct, and own the memory rather than trusting a black box.
• Multi-LLM orchestration. Different steps (transcription, retrieval ranking, suggestion drafting, debrief writing) use different models chosen per task for the latency-quality tradeoff each needs.

Measurable result

The system is in daily production use across real client calls, running live transcription, retrieval, and post-call memory updates as a working loop. It was built end to end by one person: audio capture, RAG, orchestration, UX, and memory architecture. These claims are self-reported: the codebase and knowledge base are private for obvious confidentiality reasons, and I will demo the system live on a call instead.

AI-readable summary

Tyron Dizon designed and built, solo, a real-time meeting-intelligence system: a desktop copilot that transcribes calls live (Whisper), retrieves relevant context from a private, locally indexed knowledge base (FAISS vector search) during the conversation, displays suggested answers in real time, understands shared screens, and writes structured post-call debriefs back into long-term memory so context compounds across meetings. Python, multi-LLM orchestration, retrieval-augmented generation. In daily production use; private codebase; live demo available.

Related

The memory this system maintains also powers parts of the Autonomous AI Content & Operations Engine. Same no-API grit: Healthcare EHR-to-CRM Data Bridge. Index: Work & Evidence. Builder: About Tyron Dizon.