The next generation of meeting software isn't better notes. It's making the conversation part of the work.

For the last few years, this category has been organized around what happens after a meeting ends.

Record it. Transcribe it. Summarize it. Generate action items.

That was a real improvement over typing notes while trying to listen. But I've come to think it describes only the first generation of what this software is for. The interesting question was never how to produce a better summary.

How do we make what was said in a conversation immediately usable - by the people doing the work, and by the agents working alongside them?

That question moves the product somewhere quite different.

Where this is going. Each era assumed a different answer to "what is a meeting for?" The first two treat the conversation as something to look back on. The third treats it as an input.

What I keep watching customers build

An engineering team we work with recently started wiring their own coding agent into a live meeting transcript. They built small tools to read the transcript as it was being produced, follow the discussion as it evolved, catch someone up who joined late, and combine what people were saying with the rest of their company context.

They weren't trying to get better notes.

They wanted their agent to understand the conversation alongside the codebase, the docs, the tickets, and the internal wiki - so it could help while the discussion was still live. Compare what was being proposed to what was actually implemented. Check a claim against the documentation. Draft the spec from everything said so far.

When someone in that thread asked which additional notetaker they should buy, the answer that stuck with me was that this was the wrong question. The question was which meeting-to-work capabilities they needed.

I've thought about that sentence a lot since.

Meetings are one of the largest missing pieces of AI context

Agents are rapidly gaining access to the systems where companies store their work. They can read the repository. Search Slack. Inspect Jira. Open documents. Query the warehouse. Look at a calendar.

But an enormous amount of what a company knows never lands cleanly in any of those systems.

It lives in conversation.

Someone explains why a customer actually needs the feature. An engineer raises a constraint that never makes it into the spec. A PM changes direction after hearing new evidence. An executive makes a call in the last four minutes of a meeting. A salesperson hears the same objection for the fifth time this quarter.

Sometimes those moments become a ticket or a doc. Often they don't. The result is a strange gap: AI can increasingly see the artifacts of work while missing most of the context that produced them.

The gap. Every integration effort of the last two years has been about connecting agents to systems of record. The richest source of company context isn't one of them.

From personal memory to organizational memory

This is a large part of why we're building multiplayer into Earmark.

Meeting intelligence has been stubbornly personal. You capture your meeting, you get your notes, you search the meetings you attended. But companies don't learn one person at a time. A launch involves dozens of conversations across product, engineering, sales, marketing, customers, and leadership. Nobody attends all of them, and the useful context is spread across the whole set.

Multiplayer connects the meetings a team contributes into one shared, permission-aware body of knowledge.

That's not the same as everyone suddenly seeing every conversation - it's close to the opposite. Organizational memory only works if access to it mirrors the access people already have. A product team shares one body of context. Leadership has another. A sensitive customer call is visible to a few people and no one else.

The goal was never one giant company transcript. It's that the right knowledge reaches the right person at the right moment.

Permission-aware by construction. An agent should receive your view of organizational memory, not the company's entire database. Two people asking the same question getting different evidence isn't a defect - it's the requirement.

One conversation shouldn't become five versions of the truth

Shared meeting memory creates a problem the personal version never had. If four people record the same meeting, you should not end up with four competing accounts of what happened.

So we made a distinction early: a recording is not a meeting.

Several people may capture the same conversation. Each of those captures is evidence - it has an owner, a device, a transcript, its own permissions. The meeting is the event they were all in. Earmark preserves the captures underneath while treating them as one occurrence when someone searches the team's history.

It sounds like a schema detail. It stops being one the moment this data becomes infrastructure for agents. An agent shouldn't have to guess whether three transcripts are three meetings or three angles on one. It should understand the work the way the team does.

Recording ≠ meeting. The captures are evidence and stay attached to the people who made them. The conversation is the thing that actually happened, and it's what the team's memory should be organized around.

Search is becoming reasoning

This is also why we call the other half of what we're building Agentic Search rather than, simply, search.

Conventional search answers which meeting mentioned this? The questions people actually have are harder:

• Why did we change direction on this feature?

• What concern have customers raised more than twice?

• What did we commit to that's still unresolved?

• What did engineering say about that constraint?

• How has our thinking changed over the last six weeks?

None of those are answered by matching words. Something has to identify the relevant meetings, resolve duplicate captures, respect project boundaries, pull the right passages, reason across several conversations, and return an answer grounded in cited sources.

So the two pieces divide cleanly. Multiplayer determines what knowledge you're authorized to reach. Agentic Search determines how that knowledge becomes usable context.

Nobody should have to build the plumbing themselves

Go back to that engineering team. What they assembled was clever: their meeting platform wrote a transcript to a local file, a custom tool read it on a loop, their agent consumed it, and other systems supplied the code and docs around it.

It worked. It also only worked in one meeting platform, on one operating system, and only until that platform changed the file.

That's a lot of engineering to spend on a plumbing problem. And the meeting might happen in Zoom, or Meet, or Teams, or in a room with no software in it at all.

The agent shouldn't have to know where the conversation happened.

Normalizing that is exactly what a capture layer is for, and it's the practical payoff of Earmark's botless architecture. We capture the conversation independently of the meeting platform - no bot joining the call, no per-vendor integration to maintain - and make it useful while the conversation is happening as well as long after it ends.

The plumbing problem. Every company solving this alone rebuilds the same brittle path, once per meeting platform. Normalizing capture is the unglamorous part that makes everything above it portable.

Earmark doesn't have to be the only place you use this

Which brings me to the part I've changed my mind about most.

The reflexive move in software right now is to put a chat box inside your own application and call it the AI strategy. We have one, and I think the Earmark experience should be the easiest way for most people to work with their meeting history. Most teams will never assemble a bespoke agent setup, and they shouldn't have to.

But the sophisticated teams have already chosen where they reason. It's Claude, or Codex, or Cursor, or something they built. They don't want to open another application to fetch context — they want to ask, while looking at the implementation, what did the customer actually say about this?

Competing with that is a losing framing. Our defensibility was never going to be having a better general-purpose chat interface than a frontier lab. It's holding context those models otherwise don't have: what the organization actually said, and specifically what this person is allowed to know about what the organization said.

So the division of labor I'd like is simple. Earmark hears and remembers. Your agent reasons. Your systems execute.

Which means the context has to be portable - available through the Earmark app, and equally available to whatever the team already uses. Same memory. Same permissions. Same retrieval engine. Different interface.

The stack we're actually building. Multiplayer isn't the destination and neither is Agentic Search. Together they're a permission-aware conversational context layer. The Earmark app is its first and most opinionated consumer - not necessarily its only one.

The meeting is becoming an input to work

We started Earmark because meetings clearly contained more value than the tools around them were extracting. That belief hasn't changed. What's changed is how big the opportunity looks.

The first generation of meeting AI helped people remember what happened. The next helps teams use what they've learned. The one after that makes conversational context available directly to the agents building, selling, designing, and planning alongside us.

So that's how I think about what we're building now: a permission-aware conversational memory layer for people and AI agents. Multiplayer gives that memory a shared structure. Agentic Search makes it reasonable over. And over time, it should be available wherever the work is actually being done.

The future of meeting software isn't better notes.

It's making the conversation part of the work itself.

Multiplayer and Agentic Search are rolling out now. If your team is currently building your own version of this - and a surprising number are - I'd like to hear about it.