During a summer internship Dhruv Deshpande built a small experiment called ContextCue. The project aims to preserve more than a transcript or summary from recorded meetings: the spoken discussion, important visual context from shared screens, the decisions that were made, the reasons behind them, and the source where those elements originated. The goal is a shared piece of context that can travel with work as it moves between teams.

Why this was needed

Deshpande observed that code often moved faster than the understanding around it. The product was being built by nine teams across three continents, with at least one team closely engaged with the customer. Requests could start in a customer conversation, pass through one team, and arrive at another team several time zones away. By the time engineers received the task, parts of the original meaning were sometimes missing.

Existing meeting summaries generated by tools such as Microsoft Teams typically cover a single meeting and often remain as an email for attendees. That is useful for those present, but less so for teams that pick up work later and did not see the original conversation. A plain transcript can also miss visual context: when someone points at a page, highlights part of a workflow, or indicates a performance problem on screen, words alone may not carry the full meaning.

A simple example

If a customer asks for a "faster report" and during the call points at a slow-opening page that managers open each morning before a meeting, the original meaning is that the page should load faster. Two days later a different team in another time zone might read "faster report" as "the report should finish running sooner" and plan backend work. Both meeting summaries could contain the identical instruction: "Make the report faster." Nothing in that sentence shows the teams mean different things, and the mismatch becomes visible only when the customer evaluates the result.

The sports analogy: event versus sequence

Deshpande uses a sports analogy to explain the difference between recording an event and recording the surrounding sequence. A match report can list a shot, the player and the minute, but an analyst watching the replay sees timing, pressure from defenders, and teammate movements that explain why the shot failed or succeeded. Jake M. Hofman, Daniel G. Goldstein, and David M. Rothschild framed AI as a "steroid," "sneaker," or "coach" in a Harvard Business Review article; the "coach" role—helping people make better decisions by surfacing prior evidence—guided ContextCue's purpose.

What ContextCue does

ContextCue starts from a meeting recording. Media handling uses FFmpeg, speech is transcribed with Faster-Whisper, and the transcript is stored in time-stamped segments so answers can point back to exact moments. The system also analyzes selected frames from the screen share with a vision model like Qwen VL to preserve meaning carried by visuals rather than words alone.

Instead of organizing output around meetings, ContextCue organizes it around requests or decisions. Example format:

Request: Faster report

• What the customer meant: The report page opens too slowly. (Source: customer call, shown on screen)
• Why it matters: Managers open it before a morning meeting. (Source: customer call, spoken)
• What was planned: Make the report finish running sooner. (Source: team planning meeting)
• Open issue: The current plan does not match the original request.

The format is deliberately simple and Markdown-based so humans can read it, language models can use it, and it can be versioned without a special interface. When a later meeting touches the same request, the page can be updated instead of creating another disconnected summary—shifting the unit of memory from "meeting" to "topic."

Why this matters for product work

Product managers typically assemble user stories from tickets, meeting notes, customer feedback, and engineer conversations. Important details are dispersed across these sources. If an AI model only receives the most recent meeting summary, it sees one slice of history. A ContextCue page can collect the original customer request, the business rationale, later technical constraints, product decisions, and unresolved questions, giving the model a richer starting point for drafting a user story.

The improvement comes from better input material rather than a different model.

How context grows and is accessed

Each meeting can update an existing page or create a new one. Over time this builds a topic-by-topic record of how work evolved, instead of a folder of meeting summaries where someone must remember which meeting contained a useful detail. Deshpande used embeddings and Qdrant to retrieve relevant parts of previous meetings: a question like "What did the customer mean by faster?" can return the answer with the supporting meeting and timestamp.

Some queries are simple lookups ("Find Tuesday’s meeting"). Others require combining information from multiple meetings ("Why did we change this requirement?") or searching for open questions ("What is still unresolved?"). ContextCue can expose these operations through the Model Context Protocol (MCP) so a language model can choose the right tool for the request; the protocol is less important than providing different ways to access the same shared context.

Why recorded conversations matter

Deshpande cites the 2025 Quarterly Journal of Economics paper "Generative AI at Work" by Erik Brynjolfsson, Danielle Li and Lindsey Raymond, which found that an AI assistant helped lower-skill and less-experienced customer-support workers the most, in part by surfacing information from past conversations. Companies contain a large amount of knowledge that never becomes formal documentation; it appears in explanations, customer calls, design discussions, examples, corrections, and small meeting decisions. Recorded meetings are one place where that tacit knowledge already exists.

Early benefits and the intern perspective

As a new joiner, understanding why past design choices were made can be hard: code may be readable but the rationale behind a design often is not. Tickets can say what to build without explaining the discussion that produced them. A shared context layer can make some of those questions easier to answer without another meeting or interrupting a colleague across time zones. The same idea could help onboarding, recurring meetings, team handoffs, and understanding old decisions—though these use cases still need formal measurement.

What worked and remaining challenges

Testing to date was limited. In a small test set where the correct source was already known, ContextCue retrieved the right source first about nine times out of ten and returned it within the top three results every time. That performance was encouraging, but the harder operational problems became clearer:

• Companies may use multiple meeting platforms.
• Teams may have different rules about recording and sharing.
• Some context should be visible company-wide, other context should stay within a team.
• People need notice that meetings are recorded and clarity on how recordings will be used.
• Time/versioning matters: a decision made in March and changed in April should both be preserved, with clear indication which decision is current.

These require rules for ownership, permissions, time, and trust; ContextCue does not solve all of these governance problems.

Where this could lead

Deshpande was struck by how much AI had accelerated coding while having less impact on the handoffs and shared understanding before coding began. Engineers already had powerful tools for implementing clear requirements; the slower parts were the conversations and handoffs that create that clarity.

ContextCue is an initial attempt to work on that earlier stage. The experiment is small and the technical design would need to evolve for production use, but the central idea is that meeting recordings can become more than archives: they can be a shared record of how teams arrived at decisions. If AI can help preserve that history and surface it when the next team needs it, it could improve not only coding speed but also how understanding travels across an organization.