Skip to content
LedgeurLedgeur
Guide

Your agent is guessing about your work, and the answer was in a meeting.

The Model Context Protocol is how an AI tool reads a system it does not own. Search demand for it runs at roughly 14,800 a month and nobody in the meeting-notes category has written the version of this that matters: what it means when the system being read is everything your company has said out loud.

What MCP is, in one paragraph

The Model Context Protocol is an open standard for giving an AI model access to a system: a set of named tools it can call, with typed arguments and structured results. Instead of pasting a transcript into a chat window, the agent asks for the meeting it needs and gets it.

It matters because it is the first interface in this space that is not a vendor's private API. A record exposed over MCP is readable by Claude, by ChatGPT, by Cursor, and by whatever exists in two years, without anybody building an integration for it.

Why meetings are the right thing to expose

Most of what makes a company's work legible is not written down. Why the architecture is like that, what the customer actually objected to, which decision was quietly reversed and why: all of it was said out loud in a meeting and none of it is in the documentation.

That makes the meeting record the highest-context artefact a company produces and the least reusable one. Every question an agent gets wrong about your work, it gets wrong because it is reasoning from the documents rather than from the conversations.

The security question, which is the real question

Opening a meeting archive to an agent sounds alarming, and would be if it were done badly. The wrong shape is a service account with read access to everything, because then the agent's permissions are the union of everybody's.

The right shape is that the agent runs as a person. A token resolves to one user's session, the database's row-level security decides what comes back, and an agent cannot read a meeting its owner could not. That is checkable rather than promised, because it is enforced in the database and not in application code.

What this looks like in practice

Ask your coding agent why a service was built the way it was, and it reads the design review. Ask an assistant what a customer has raised across four calls, and it searches the transcripts rather than the CRM notes somebody wrote afterwards.

The useful tools are unglamorous: list the meetings, search them, get one in full with speakers and timestamps, list the open action items, list the people. Five tools cover almost everything anybody asks.

Where this is going

The category's best-funded players are converging on the same idea from the other direction: meetings as the seed of a broader context layer, held in their cloud, queried through their product. That is a real answer and it produces exactly one company that can read your history.

The alternative is an open protocol over a record you hold, under a licence you can fork. Both will exist. It is worth deciding which one you want before you have four years of meetings inside it.

Try it on one real meeting

Free for one person, permanently. Nothing is uploaded, and no account is needed to record.