Searching 6 weeks of meetings to find one decision: why we built it

Maya, a senior PM on our platform team, spent two full days last quarter looking for a meeting.

Specifically, she was looking for the meeting in which we'd decided to deprecate the v1 API. She remembered we'd decided it. She remembered Alice had pushed back. She remembered Bob had eventually agreed if we extended the timeline. She remembered the date was sometime in March, maybe early April. She just couldn't find the meeting.

She searched Slack. There were thirty-seven mentions of "v1 API" across various channels, none of which were the meeting decision. She searched the engineering wiki. The deprecation was documented, but the decision — the conversation, the constraints, the people who'd agreed — wasn't. She asked Alice. Alice remembered the meeting but couldn't remember the date. She asked Bob. Bob remembered the date but couldn't remember the decision.

After two days, Maya gave up and made the decision again. We re-litigated something we'd already agreed on, this time with a slightly different set of people in the room, who reached a slightly different conclusion than the first meeting. And now there were two versions of the decision floating around the org.

This is the moment we decided to build meeting search.

The problem isn't memory. The problem is retrieval.

For a long time, organizations have treated meeting memory as a personal asset. The decisions live in the heads of the people who were in the room. If you want to know what was decided, you ask someone who was there.

This works fine for small teams. It breaks badly at scale, and it breaks in three specific ways:

1. Decay. Three months after a meeting, even attendees remember the gist but not the specifics. The exact wording of the agreement, the constraints that were negotiated, the dissenting voice — those fade.

2. Drift. Without a single source of truth, every person who was in the meeting remembers it slightly differently. When you re-discuss, the version that "wins" is whoever speaks first or most confidently — not the actual decision.

3. Departure. When the person who held the memory leaves the company, the decision is gone. We've all inherited a codebase where some sentinel constant has a comment that says "do not change — we decided this in a meeting" and there is no record of which meeting.

Writing things down helps. Decision logs help. But the activation energy of writing a decision log is high enough that most teams don't do it consistently. And even when they do, the log captures the conclusion but not the reasoning.

The reasoning is what you need six weeks later when somebody asks "why didn't we just X?"

What we wanted from a meeting search engine

When we sat down to scope this, we listed the queries we'd actually want to ask. Not the queries that sound impressive in a demo, but the queries that come up in real work.

Here's our list, ranked by frequency:

1. "When did we decide X?" — by far the most common.
2. "What did we say about X in the last month?"
3. "Who's been raising the X concern repeatedly?"
4. "Show me every meeting where X was discussed."
5. "What did Alice say about Y last quarter?"
6. "Which meetings are still open action items linked to?"

Notice that none of these are full-text queries in the way that, say, GitHub code search is a full-text query. They're queries about decisions, people, and time — all wrapped in fuzzy natural-language phrasing.

This shaped how we built the index. A naive approach would be to dump every meeting transcript into Elasticsearch and call it done. We tried this. It surfaced too much noise. "v1 API" matched every casual mention of the API across six weeks of standups, retros, design reviews, and 1:1s — most of which had nothing to do with the deprecation decision.

What we needed was a search engine that understood the difference between mentioning a topic and deciding about it.

The decision graph

Internally we call it the decision graph. It's a layer on top of the raw transcript that extracts and labels:

• Topics: clusters of related discussion across meetings
• Decisions: moments where the conversation shifted from exploration to commitment
• Stakeholders: who was present, who spoke, who pushed back
• Outcomes: what was agreed, what was deferred, what was rejected
• Confidence: how strongly the AI believes the conversation actually reached a decision

The last one matters more than we expected. The model has to distinguish "we should probably do X" (vague intention) from "we agreed to do X by Friday" (commitment). It's not perfect. But it's better than what humans do when they go back and try to remember.

When Maya re-ran her query against the decision graph for "deprecate v1 API", she got back a single result with 94% confidence: a 38-minute platform sync from March 12. The relevant moment was at 23:18. Bob said "okay, fine, but only if we give external partners 90 days." The decision was logged with the constraint attached. Two-day search, reduced to two seconds.

What we got wrong on the first try

We built v1 of the search and showed it to the team. They mostly ignored it.

The first version had a great backend and a terrible frontend. We'd given people a search bar and expected them to know what to type. They didn't. They typed "v1 deprecation" and got six results and no idea which one was the decision. They typed nothing at all and saw an empty page.

We made three changes that turned it around:

Recent decisions feed. Instead of an empty homepage, we showed the last twenty decisions across all the user's meetings, with a one-sentence summary of each. Suddenly the search tool was useful even when you weren't searching for anything specific — it was a news feed of organizational commitments.

Natural-language input. We let people type "when did we decide to deprecate the v1 API" instead of forcing them to construct a query. The model parses the intent and routes it. This sounds obvious in 2026 but a lot of internal tools still make you fill out a form.

Cited evidence. Every search result includes the timestamp link into the transcript and the actual sentence that was said. You don't have to trust the model's summary — you can click through and hear Bob say "okay, fine, but only if we give external partners 90 days" in his own voice.

The cited evidence turned out to be the single feature that made people trust the tool. Without it, the search was a black box. With it, the search was an index — and an index, by definition, has to point at something real.

What we use it for now (besides Maya's question)

Six months in, the most common use cases are:

Onboarding. New hires search the meeting archive for the projects they're joining. They get up to speed in days instead of weeks. The senior engineers don't have to do as many "let me tell you the history of this codebase" calls.

Cross-team coordination. When the design team needs to know what engineering decided about a feature, they search the engineering meeting archive instead of pinging six people. The pings dropped by maybe 60%. (We measured. It's real.)

Manager catch-ups. Engineering managers who skip a week of standups can run a quick query: "what blockers came up while I was out?" — and get a five-minute summary instead of reading every transcript.

Decision archaeology. This is Maya's original use case, and it remains the most valuable. Every team needs to occasionally re-derive why a decision was made. The transcript, with its full context, is a vastly better source than anyone's memory.

What we still haven't figured out

Two open problems we're working on:

Private meetings. Some conversations should never be searchable across the org. 1:1s, manager-skip-level calls, sensitive HR discussions. Our current model is private-by-default with explicit opt-in to org-wide search. This is probably right but it creates a long tail of useful context that ends up unsearchable. We don't have a great solution.

Conflicting decisions. Sometimes two meetings reach conflicting decisions because the participants didn't know about each other's meetings. The search engine surfaces both, but it doesn't yet tell you which one is operative. A human still has to reconcile. We're prototyping a "decision lineage" view that shows how a decision has evolved through subsequent meetings, but it's not shipping yet.

The bigger thing

Meeting search is one of those features that sounds boring until you've used it. It's not a flashy demo. It doesn't have a great hero shot. But it changes how an organization remembers itself.

Before search, every meeting was a private event with a public summary. After search, every meeting is a piece of organizational memory that anyone can revisit. Decisions become durable. Context becomes inheritable. New hires stop having to ask "why do we do it this way?" because they can find out.

Maya, by the way, has stopped re-deriving decisions. She just searches. The two days she spent looking for the v1 deprecation meeting last quarter is the most expensive search query she'll ever run, because it's the one that convinced us this had to exist.