Theories
Stay up-to-date on our team's latest theses and research
Stay up-to-date on our team's latest theses and research
AI notetakers are a dime a dozen, so what pushed us to make our own?
At Theory, we meet hundreds of times per month to discuss markets, opportunities, strategies, and internal tools. With so many conversations, critical insights can get lost—buried in personal notes, scattered across individual transcribers, or, in the worst case, never captured at all.
We needed a transcription system that could sift through the clutter and make our data actionable. A system that could quickly surface insights from transcripts, bring forward relevant past conversations when reviewing company records, and turn discussions into meaningful to-dos, routing them to the correct teammate.
Designing our own notetaking pipeline allowed us to customize these workflows exactly how we needed.
So, how did we do it?
Our stack consists of four parts:
Together, these layers turn raw conversations into structured, searchable knowledge.
One of our first technical hurdles emerged from a simple scenario: when multiple team members attend the same meeting, several unique webhooks are triggered. Without proper deduplication, our system would process the same meeting multiple times, creating:
The Solution: Cloud Tasks with Deterministic Keys. This approach eliminated duplicate processing while maintaining zero-latency webhook responses. The leading insight was that Cloud Tasks’ built-in deduplication handles the complexity of distributed state management, while our deterministic key generation ensures semantic equivalence across multiple webhook sources.
During each meeting, a significant portion of our insights, to-dos, and follow-up research revolves around specific companies. Directly linking company records to relevant transcripts and documents greatly enhances our ability to organize and retrieve information. Identifying these connections is a classic NLP challenge known as Named Entity Recognition (NER).
To address this, we combined multiple tools with our existing infrastructure to automatically detect potential named entities within transcripts. These entities are then linked to corresponding company records through a search over our company database—a system similar to what underpins our broader universe of companies.
The heart of our system is the summarization and extraction pipeline. Rather than asking the LLM to directly generate a summary, we designed a structured thinking process that guides the model through thorough analysis before synthesis.
The prompt first instructs the model to classify the meeting type, distinguishing between structured recurring meetings and anything ad hoc, enabling context-appropriate summarization strategies. For example, during pipeline meetings, we emphasize action items and diligence follow-ups. This flexibility allows us to quickly modify the prompts we use for these extractions.
To ensure reliability, we implemented a robust citation system that links every claim and to-do in the summary back to specific moments in the transcript. The LLM is instructed to use citation tags that reference line numbers where supporting evidence can be found.
We provide these summaries as Notion pages and utilize the block-level linking system to give users a powerful UI to explore the call notes and summaries.
The workplace is moving toward consolidating data within organizations, making it easier to search, share, and use across multiple systems. While off-the-shelf notetaker tools can cover the basics like transcripts and email follow-ups, we chose to build something deeper. Our approach allows us to seamlessly connect this data with the rest of our internal tooling, even integrating with our team’s MCP server. Individual meeting transcripts become part of a larger, living dataset that links directly into our existing knowledge graph.
“When the cost of creating things approaches zero, where does the value lie?” Earlier this month, we met in Berkeley, California, to talk about AI workflows—not in the abstract, but real ones people actually run every week. AI automations crafted by the user themselves, not a disjoined stakeholder’s ticket. These demonstrations of ‘personal software’ captured a preview of the future that so many folks see coming. Three friends opened their laptops and showed us how they’re using models as patient, tenacious co-workers: capturing information, keeping creative work on the rails, and taming calendars and inboxes to create more time for human work.
Backing up, this event was conceived by Hamel Husain and I to sate his frequent inquiries: ‘how are you using AI’, ‘tell me about your workflows’, and ‘are you using any new AI tools this week?’. We wanted to craft a show-and-tell with some of the folks living in the future to tell us what’s actually saving them time, or expanding their aperture of focus.
Tomasz Tunguz went first and made a strong case for compressing the firehose. Tomasz leads Theory Ventures as its General Partner, and his workflow is designed to support that. He’s built a pipeline that watches a slate of podcasts, turns speech into text, then synthesizes what matters: the three or four themes worth caring about, the quotes that actually support those themes, and even a “contrarian take” prompt emulating Peter Thiel’s strategy. The punchline isn’t a dashboard—it’s a daily email he can read in fifteen minutes instead of forty hours listening.
Hamel responded by asking if any of these podcasts are ‘incompressible’; in a testament to the fidelity of this system, Tom admitted that he rarely “goes back to listen”; but he does interrogate the transcripts, asks targeted questions against them, adds additional research queries, and collates follow-ups into a task list so the research yields outcomes. Along the way, the system quietly flags net-new companies and pushes them into the CRM, integrating into the rest of the firm’s virtuous cycle.
Tom’s pipeline starts with the audio. He pulls episodes down locally, runs Whisper on his GPU to transcribe (cheap and fast), then passes the raw transcript through a small local model whose only job is to strip filler—ums, uhs, throat-clears—so the expensive part that follows stays lean. In his words, input volume drives 80–90% of LLM cost, so the pre-shrink matters. With the text compacted, he hands it to a “real” model (Claude Sonnet) that executes a long prompt: split the episode into 5–15 minute segments, summarize each segment’s argument, lift direct quotes, and extract entities (people, companies) that might deserve a look. From there, a little glue kicks off a downstream routine to check those entities against the CRM and create records for the net-new ones. The outputs are deliberately boring and useful: a daily summary email for him, plus a PDF to his Kindle; behind the scenes, the system often surfaces a couple of new startups worth tracking. He’s running it as a local CLI right now to keep iteration tight while he gets the loop right.
Greg Ceccarelli followed by zooming in on intent; his workflow is incredibly spec-driven, communicating the objectives and not the tool directions. He showed a code-driven video workflow where scenes live as components, the timeline updates the instant you change a prop, and “edits” are just commits. It’s the opposite of pixel-pushing: your source of truth is the spec and prompt. One of Greg’s keys to success is monitoring and iterating on the trail of chats that led to the code. Via a tool his company built, he’s able to store the upstream conversations in addition to the generated files.
Greg also introduced the term “dead looping” for that familiar feeling of issuing the same prompt three times and waiting for the model to suddenly become insightful. He advised changing the frame, starting a new session, and resetting the context that’s poisoning the agent.
Finally, Claire Vo closed the loop by putting agents on the calendar and content grind. Claire seems to have conquered the “Sunday Scaries”: an agent that walks three calendars, pulls event names and attendees, checks email to remember who a meeting is with and why, and spots places to consolidate time. In case you are worried these tools lack heart, this tool auto-blocks a morning window to walk her kids to school if the day allows it. The brief lands in Slack; automation that sharpens the edges of the start of the week.
Similarly, her content flow reduced the frictional steps of producing a podcast. Feed a recording and transcript into a generator primed on your own archive to get a draft that’s 80–85% there, getting her to the part of the workflow that requires real taste.
Tomasz, Greg, and Claire provided varying perspectives, but all with an underlying theme: selection, specification, and synthesis. Some practical recommendations are to start small: pick one place where you already spend energy—the media you consume, assets you produce, logistics that drain you—and sketch the loop you wish existed. Capture, compress, and connect it to the surface where you’ll actually act. Then turn the crank once.
“All teams will henceforth expose their data and functionality to LLMs, and anyone who doesn't do this will be fired.” - Jeff Bezos (theoretically)
Jeff Bezos famously mandated this for web services when starting AWS, and it would be a likely update for the LLM era.
When building for developers, this discipline made AWS services “externalizable by default,” propelled Amazon’s platform strategy, and helped cement microservices as modern dogma.
When building for LLMs, this discipline means having the right context from a variety of systems easily accessible. Although they are incredibly powerful, LLMs are only as intelligent as the context they have.
At Theory Ventures, we’re investors, but we’re also all builders, creating internal software to move fast. Our goal: answer investor questions about any company in seconds: from “What’s new since the last call?” to “Show revenue by cohort” to “Summarize the last three meetings.”
As a simple example, let’s consider an investor writing a company memo to share internally; information about the company is comprised from several different sources:
Remembering and managing all of these different data sources and copying them is a lot of work, but what if all that context could be available to the investor’s LLM just by mentioning the company name?
Model Context Protocol (MCP) has emerged as a simple and robust way to give LLMs the right context. MCP is a standardized protocol that empowers LLMs to connect with data sources, tools, and workflows.
A well-designed MCP enables users and agents to complete their work wherever that work is happening: in chat or in a container. MCP is intentionally boring in all the right places: predictable schemas, explicit descriptions, and a clean contract between the system and the model.
We deploy an MCP server on FastMCP Cloud so the LLM client can call it from anywhere without custom infrastructure.
LLMs don’t magically know our world. They need:
So we exposed one MCP tool that the model can reason about: company_context. Given a company name or domain, it returns a structured summary with IDs, core metadata, notes, historical activity, and (when applicable) financials. Internally, this tool orchestrates multiple services, but the LLM only sees a single, well‑documented interface.
What the tool returns at a high level:
Here’s the company_context tool’s internal orchestration:
.png)
# Pseudocode – orchestrating a company context query
def get_company_context(company_name: str):
company_id = get_company(company_name)
core = fetch_core_company_data(company_id)
notes = fetch_notion_pages(company_id)
history = fetch_historical_data(company_id)
financials = None
if core.get("is_portfolio_company"):
financials = fetch_financials(company_id)
return serialize_company_data(core, notes, transcripts, history, financials)
This tool returns a compact, documented schema so the model knows what it returns and how to consume it. For example:
{
"name": {
"value": "Company A",
"description": "Public-facing name of the company"
},
"id": {
"value": "123444ee-e7f4-4c9f-9a4e-e018eae944d6",
"description": "Canonical company UUID in our system"
},
"domains": {
"value": ["example.com", "example.ai"],
"description": "Known web domains used by the company"
},
"notion_pages": {
"value": [
{"page_id": "abcd1234", "title": "Intro & thesis", "last_edited": "2025-07-28"}
],
"description": "Notion pages with analyst/investor notes"
},
"is_portfolio_company": {
"value": true,
"description": "Whether the company is in our portfolio"
}
}
This isn’t fancy agent pixie dust; it’s just clear contracts that let the model get access to the context it needs without human input.
If you remember only one thing, make it this: Expose your service’s core functionality as MCP tools and make them excellent. That’s the shortest path to truly AI‑native software. It’s the clearest mandate for the next decade.