This summer, I built a small experiment called ContextCue. The idea came from something I kept seeing during my internship. The engineers around me were using AI everywhere in the software development process. GitHub Copilot and Claude models helped with specs, code, reviews, and tests. The team also maintained reusable skills that taught coding agents how the team worked. One of those skills could take a UI design and turn it into working frontend code.
The code was moving faster, but the understanding around the code did not seem to move faster with it. The software was being built by nine teams spread across three continents, with one team working closely with the customer. A request might begin in a customer conversation, move through one team, then reach another team several time zones away. By the time the work reached engineering, some of the original meaning could be missing.
That was the problem I wanted ContextCue to explore. ContextCue takes recorded meetings and tries to preserve more than a transcript or summary. It keeps the spoken discussion, important visual context from the screen, the decisions that were made, the reasons behind them, and the source they came from. The goal is to create a shared piece of context that can move with the work from one team to another.
It is still an experiment, but the problem behind it felt very real. As far as I could see, a lot of time in distributed software teams went into reaching a common understanding before the coding even started. AI was already helping with the final stages of software development. I wanted to see whether it could help earlier, while teams were still trying to understand what they were building and why.
Where the context disappears
Meetings were already being recorded, and tools like Microsoft Teams could produce an AI summary. On my team, that summary often arrived as an email and stayed there. That worked well enough for the people who attended the meeting. It was less useful for the team that picked up the work later, especially if that team was in another country and had not seen the original conversation.
There were two other problems. A summary usually covered one meeting, while the understanding behind a feature was often built across several. Different teams might discuss the same request days apart, each adding a new constraint or interpretation.
A transcript could also miss important visual context. Many of our conversations involved screen sharing. Someone might point at a page and say, “This is too slow,” or highlight a part of a workflow while explaining what needed to change. The words alone did not always carry the meaning. That is where I started thinking about context as something larger than a transcript.
A simple example
Imagine that a customer asks for a “faster report.” During the call, the customer shares a screen, points at a page that is slow to open, and explains that managers use it every morning before a meeting. Everyone on that call understands that “faster” means the page should open more quickly.
Two days later, another team in another time zone discusses the same request. Nobody in that meeting saw the original screen. They read “faster report” as “the report should finish running sooner” and begin planning backend work. Both meeting summaries might contain the same phrase:
Make the report faster.
Nothing in that sentence shows that the two teams mean different things. The problem only becomes visible when the customer sees the result.
This is a simple example, but it captures the issue I kept noticing. Requirements move through people before they ever become code. If the meaning changes during that process, AI can help a team implement the wrong interpretation very efficiently.
The sports version of the same problem
Sports gave me another way to think about it. Imagine a soccer match where a player misses a late chance to score a goal. The match report can record the shot, the player, the minute, and whether it was on target. Those facts are useful, but a coach watching the replay sees much more. The winger may have delivered the ball too early. A defender may have forced the striker onto a weaker foot. A teammate may have made a run that opened the space.
The event is only one part of the story. A coach learns from the sequence around it.
Jake M. Hofman, Daniel G. Goldstein, and David M. Rothschild use a related sports framework in a Harvard Business Review article where they describe AI as a steroid, a sneaker, or a coach, depending on how it helps people. The “coach” idea is the one that stayed with me. A useful AI system does not only help people produce more. It can also help them make a better decision by bringing forward the evidence and experience that came before. That is close to what I wanted ContextCue to do for teams.
What I built
ContextCue starts with a meeting recording. FFmpeg handles the media, and Faster-Whisper transcribes the speech. The transcript is kept in time-stamped segments so that any later answer can point back to the moment where something was said.
The system also looks at selected frames from the screen share using a vision model such as Qwen VL. That helps preserve cases where the meaning depends on what someone was pointing at rather than only on the words they used.
The final output is organized around a request or decision instead of around a meeting. For example:
# 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. I used Markdown because a person can read it, a language model can use it, and it can be stored or versioned without depending on a special interface. When a later meeting touches the same request, the page can be updated rather than creating another disconnected summary. That changes the unit of memory from meeting to topic.
Why that matters for product work
One of the clearest uses I saw was product management. A product manager writing a user story usually works from some combination of tickets, meeting notes, customer feedback, and conversations with engineers. The important details are often spread across all of them.
If the product manager gives an AI model only the latest meeting summary, the model sees only one slice of the history. A ContextCue page can give it more. The page might contain the original customer request, the business reason behind it, a technical constraint raised later, a decision from product, and an unresolved question that still needs an answer.
That gives the model a much better starting point for creating a user story. The model itself has not changed. What improves is the material it has to work from. This is an important distinction because a lot of AI work focuses on prompts and models, while the quality of the context often decides whether the output is useful.
How the context grows
Each new meeting can update an existing page or start a new one. Over time, that creates a topic-by-topic record of how the work evolved. That is different from having a folder full of meeting summaries. A folder forces someone to remember which meeting contained the useful detail. A topic page collects the relevant pieces in one place.
The stored context can also be searched. I 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 along with the meeting and timestamp that support it.
Other requests need something more structured. “Find Tuesday’s meeting” is a lookup. “Why did we change this requirement?” may need information from several meetings. “What is still unresolved?” should look for open questions rather than just similar text.
ContextCue can expose those operations through the Model Context Protocol (MCP), so a language model can choose the right tool for the request. The main point is not the protocol itself. The useful part is that different types of questions can use different ways of accessing the same shared context.
Why recorded conversations are worth keeping
One study made me think recorded conversation was especially valuable. In “Generative AI at Work,” published in the Quarterly Journal of Economics in 2025, Erik Brynjolfsson, Danielle Li, and Lindsey Raymond studied an AI assistant used by customer-support workers.
They found that lower-skill and less experienced workers improved the most. The system appeared to help them communicate more like higher-skill workers. What interested me was that some of the useful knowledge came from past conversations.
A company contains a lot of knowledge that never becomes a formal document. It appears in explanations, customer calls, design discussions, examples, corrections, and small decisions made during meetings. Recorded meetings are one place where that knowledge already exists.
The first benefit I noticed was personal
As an intern, one of the hardest parts of joining a large project is learning why things are the way they are. You can read the code and still not know why a certain design was chosen. A ticket may describe what to build without explaining the discussion that produced it.
The usual solution is to ask someone. That is often the right thing to do, but it also means interrupting someone who already has work to finish. A shared context layer could make some of those questions easier to answer without another meeting or another message across time zones.
The same idea could help with onboarding, repeated meetings, handoffs between teams, and situations where someone needs to understand an old decision. I can see those possibilities from where I sat as an intern, but they still need proper measurement.
What worked, and what is still hard
My testing so far is limited. I created a small set of questions where I already knew the correct source. ContextCue retrieved the right source first about nine times out of ten and returned it within the top three results every time in that test set.
That was encouraging, but it also made the harder parts of the problem clearer. A real company may use several different meeting tools. Different teams may have different rules about what can be recorded. Some context should be visible across the company, while other context should stay within a team. People need to know when meetings are being recorded and how those recordings will be used.
There is also a time problem. A team may make one decision in March and change it in April. The March decision should not disappear, because it explains how the team got to the current position. At the same time, the system should make it clear that the April decision replaced it.
That kind of history is useful, but it is more complicated than simple search. It requires rules around ownership, permissions, time, and trust. ContextCue does not solve all of that.
Where this goes
The thing that stayed with me from the internship was the contrast between how much AI had changed coding and how little it had changed the handoffs around coding. The engineers already had strong tools once a requirement was clear. The slower part often happened before that point, while teams were trying to understand a request, add constraints, pass it to another group, and keep everyone aligned.
ContextCue was my first attempt at working on that part of the process. The experiment is still small, and the technical system will need to change if it ever moves into a real company environment. The useful idea, for me, is that meeting recordings can become more than archives. They can become a shared record of how a team arrived at a decision.
If AI can help preserve that history and bring it forward when the next team needs it, then it may improve more than the speed of writing code. It may improve how teams carry understanding from one part of the organization to another.
Log in
