Dan Shipper interviews Chris Pedregal, cofounder and CEO of Granola, on the AI & I podcast about building the AI meeting notetaker, which recently raised a $125 million Series C at a $1.5 billion valuation. Pedregal explains why he isn't rattled by competition from Notion, OpenAI, and Zoom, and why Granola is betting on owning the entire meeting workflow—preparing people for calls, helping them act afterward, and exposing meeting context to any agent (Claude, Codex, or others) via its API and MCP. Topics include why starting a company feels like a knife fight, Granola's counterintuitive view on competition, the "pirate and architect" framework for early-stage product teams, Granola's "shaping" and "validation" phases for building features, living inside Codex and the case for "Codex-native apps," Granola's "handrail" philosophy, why the company pre-generates millions of mostly unopened meeting briefs, and what a transcript alone can never capture. Timestamps: 00:00:59 Introduction 00:01:57 Why starting a company feels like a knife fight 00:04:33 Granola's counterintuitive view on competition 00:10:44 Dan's "pirate and architect" framework for structuring early-stage product teams 00:13:09 How Granola's "shaping" and "validation" phases work for building new features 00:18:17 Why Dan lives almost entirely inside Codex 00:24:40 The case for "Codex-native apps" 00:35:37 Granola's "handrail" philosophy 00:38:12 Why Granola is betting on owning meeting-adjacent context instead of competing as a general agent 00:44:19 What a transcript alone can never capture # Video Identity Observations ## Source Overview - **Video:** "Granola's Chris Pedregal on Building a $1.5B AI Company" - **Observable format:** Long-form interview podcast hosted by "Dan" (Dan Shipper), with a guest co-founder/CEO. Sponsorship reads for **Every** ("Every is the only subscription you need to stay ahead of the curve in AI... Visit every./subscribe") and **Adio** ("the CRM for the agent-native world... Visit adio.com/every") indicate the channel is affiliated with Every, a subscription media/products business. ## Intended Audience The presentation addresses **AI practitioners, founders, and builders**, not general consumers: - Sponsor pitch frames the audience as people who want to "stay up to date with the latest models and using new tools." - Deep technical/workflow discussion: agent interfaces, "MCP," "CLI," "Codex native applications," token-spend economics, pre-generating millions of meeting summaries. - Host explicitly frames early adopters as proxies for the future mainstream: *"The people who want to decipher these general-purpose tools and build these workflows are what ordinary people will be doing in a few years."* ## Claimed Scope - **Claimed positioning (creator statement):** Every helps subscribers "separate what's important from the noise" in AI — a curation/edge-keeping claim. - **Demonstrated scope:** Practitioner-level interviews about how AI-native work is actually being built — org design ("pirate and architect"), product philosophy, competitive strategy against OpenAI/Notion/Zoom/Anthropic, and hands-on tool workflows (Codex, Slack agents, Claude). ## Self-Description Evidence - Host self-describes as a builder, not just a journalist: *"I've been building companies for a long time and this is the first one that's actually growing... We're already 30 people."* Every runs its own products (Monologue, Kora, Proof, Plus One, Victor). - Host cites editorial philosophy: a journalism professor's line — *"The last thing the world needs is another profile that glorifies someone"* — positioning the show as anti-hagiography, honest founder conversations. - Outro (possibly AI-generated or stylized) markets the show as "the epitome of genius... pure, unfiltered knowledge bombs about ChatGPT" — an enthusiastic, personality-driven promotional voice centered on host Dan Shipper. ## Presentation Patterns (Observed, Not Claimed) - Heavy emphasis on **candor and insider access**: guest allowed to say "we don't know" repeatedly; host highlights guest honesty as a differentiator ("you're very honest about what you're facing"). - Peer-to-peer dynamic: host experiments with the same tools as guests, testing products pre-release (references to "Fable"). - Transcript shows apparent translation artifacts (e.g., "Claude Tag" for "Claude Cowork," "Kora"/"Codecs"/"Codeex" variations), suggesting this copy may be machine-translated — a production-quality observation, not a channel-identity claim. ## Notes for Synthesis Channel identity evidence points to: **Every's "AI & I" podcast — a builder-practitioner interview show by Dan Shipper, monetized via Every subscriptions and sponsorships, differentiated by candid, technically deep conversations with AI company founders.** This is one episode's evidence; channel-wide conclusions require corroboration. # Delivery Observation Document ## Speaker: Chris Pedregal (with interviewer Dan Shipper) > **Caveat:** The transcript appears to be a machine translation into Spanish and back (e.g., "Codeex" for Codex, "Adio" for Attio, "Claude Tag" for Claude Code). Quotations reflect the transcript as supplied. --- ## 1. Tone - **Deliberately anti-glamorizing.** He actively resists founder-bravado framing: > "I had a professor in journalism school who basically said, 'The last thing the world needs is another profile that glorifies someone'... it's all a difficult struggle day after day." - **Comfortable with uncertainty in public.** He repeatedly flags open questions rather than presenting resolved positions: > "I still don't quite know how to measure it." > "I haven't fully deciphered it yet." - **Conversational warmth toward the host**, with reciprocal energy ("I couldn't be more excited to chat"; "I understand you, friend"). --- ## 2. Recurring Vocabulary and Phrases - **"Best in the world at [narrow thing]"** — his core strategic framing, used at least three times: > "to be the best in the world at everything related to meetings" > "we should simply be 5 times better than anyone else in the world" - **"Knife fight"** — his anchor metaphor for startup life, introduced and revisited ("It's simply a knife fight when things are going well and when they're not"). - **"Still experimenting" / "we're still here"** — a pattern of emphasizing ongoing, unfinished states. - **Hedges as rhythm:** "I don't know," "maybe," "it's like," and "right?" appear constantly as discourse fillers, giving the delivery a thinking-out-loud texture. --- ## 3. Teaching Habits: Analogy-First Explanation The most distinctive pattern is explaining abstract concepts through compact, vivid metaphors, often two or three per topic: - **Knife fight** — difficulty of startups at all stages. - **Surfboard on a big wave** — operating at the limit of capability: > "it's like you're on a big wave on a surfboard, desperately trying not to fall off." - **Pirate and architect** — a named two-role model for early product building: > "there are two roles that matter: one is called the pirate and the other is called the architect." - **Handrail on a staircase** — his product-philosophy analogy: > "you never notice the handrail... but the moment you trip, your hand flies off; it needs to be there, it needs to be strong." - **Bones and ligaments/muscles** — software vs. AI: > "AI is the ligaments and muscles, and the software has to be the bones." - **Complex vs. complicated problems** — borrowed framing from a class, applied to strategy. **Assessment:** This is the most stable pattern in the video — at least six distinct analogies across the conversation, each unpacked with a concrete scenario. --- ## 4. Teaching Habits: Concrete Anecdotes as Evidence Abstract claims are almost always followed by a specific story: - The Verizon internet-transfer Codex anecdote to illustrate agent-driven browsing. - The pre-meeting summary feature ("you're 2 minutes late to a meeting... 'Wait, who the heck is this person?'"). - The sales user who built a Claude-generated microsite populated via Granola's MCP. - The Hugging Face founder who abandoned his Cloud Code workflow: *"he said to me, 'Man, I built an incredibly complex workflow... and shut it down because yours was better.'"* --- ## 5. Communication Patterns - **Pre-emptive humility before opinions:** he flags his answers as incomplete before giving them — "it's going to sound like one of those absurd answers about competition" — then delivers the full view anyway. - **Self-correction mid-sentence** and restarting thoughts ("It's like, it is, it is, um..."), consistent with unscripted, exploratory speech. - **Deflecting credit/heroism:** rejects "we were first" framing — "we weren't the first to take notes in meetings... I can't say, 'Oh, how dare you be inspired by what we did?'" - **Naming his own concepts:** coins portable terms ("time travel" problem, "Codex native applications," "pirate/architect"), suggesting a habit of packaging ideas as teachable units. - **Turn-taking reciprocity:** frequently bounces questions back to the host ("But what are you doing?"; "Do you have a philosophy on this at Every?"), making the exchange genuinely dialogic rather than monologue-style. --- ## 6. Stable Patterns vs. Isolated Moments **Stable (repeated across the conversation):** - Analogy-based explanation (6+ instances). - Hedge-then-commit structure ("I don't fully know, but..."). - "Best in the world at X" strategic vocabulary. - Concrete anecdote as evidence. - Open-endedness about unresolved org/product questions. **Isolated (thin evidence, do not over-generalize):** - The journalism-professor anecdote (one instance). - Playful banter about eliminating job titles ("I'm always flirting with the idea of eliminating them") — mentioned once; unclear if a serious position. - Humor moments ("we're either still in diapers"; "maybe you seemed very stressed in that meeting") — a lighter register that surfaces only near the end. --- ## 7. Overall Delivery Profile Pedregal's observable delivery style combines **metaphor-dense teaching**, **explicit acknowledgment of uncertainty**, and **anecdote-backed specificity**. He consistently resists polished-founder framing, preferring working-through-problems in real time — the sentence-level hedges and self-corrections are part of that register rather than verbal noise to be discounted. # Observation Record: Granola's Chris Pedregal on Building a $1.5B AI Company **Format:** Interview/podcast conversation **Speakers:** Dan Shipper (host, Every); Chris Pedregal (co-founder and CEO of Granola, identified by host introduction). Some speaker attribution is inferred from conversational turn-taking where explicit markers are absent. --- ## 1. Context and Framing (Host: Dan Shipper) - Describes Granola as "one of the first AI apps where people said, 'Wow, this actually works and it's useful.'" - States the company has ~55 people (Chris later says "between 60 and 70," an internal inconsistency preserved here) and has raised at a **$1.5 billion valuation**. - Notes a prior conversation (December 2024, though he also says "two and a half years ago" — contradiction preserved) about "putting soul into your product." --- ## 2. Chris Pedregal: Startups as "Knife Fights" - **Core claim:** Startups are hard even when succeeding: > "I thought startups were only hard when they didn't work. It turns out that they're also really difficult when they actually work." - **Reasoning:** A startup is by definition "always fighting to survive" — like being "on a big wave on a surfboard, desperately trying not to fall off." Founders are "always doing things you don't know how to do." - Dan Shipper concurs, noting his own company (Every, ~30 people) is his first that is "actually growing." - Specific growth challenge cited: scaling from Socratic (12 people) to 60–70 people at Granola; organizing people and maintaining product coherence at scale is "a very complex problem." --- ## 3. Competition: "The Beginning of a Computer Revolution" - Chris's stated view on competitors copying Granola (Notion, OpenAI, Zoom): > "We're in the very, very early stages of a computer revolution and... what's come so far will seem insignificant compared to what's coming soon." - **Meeting notes are not the end goal:** "Meeting notes are useful, but many things are going to change... just because people use us today doesn't mean they'll use us for that in the future if we're not the best at what comes next." - **Qualifications he offers:** - Granola was *not* first to AI meeting notes — "we were very inspired by things that already existed," so he cannot object to being copied. - Copying "has affected us much less than I thought" — growth rate unchanged after Notion/OpenAI/Zoom launches. - Counter-qualification: "we're still a drop in the ocean compared to what we'd like to be." --- ## 4. Organizational Roles ### Chris's evolving position - Granola still uses titles (designer, PM, engineer) with "three or four" direct roles; he is "always flirting with the idea of eliminating them." - **Open tension he names:** roles create clarity of responsibility but eliminating them creates heavy communication overhead ("What exactly are you going to do in response to what I'm going to do?"). - He explicitly says he hasn't solved this: "We're still experimenting... I don't know if we should have them." ### Dan Shipper: "Pirate and Architect" model - For early products, two roles matter: - **The pirate:** builds as fast as possible to find something valuable; mixes technical/product/design work. - **The architect:** partners to turn findings into sustainable, scalable systems. - **Rationale:** AI tools make architects portable — one architect can serve multiple products by using Claude/Codex to rapidly map codebases and execute rewrites. - Dan notes Every does have independent designers for mature products; agrees "there's no single answer." ### Chris's "stages" process (Every) - A shaping → validation → build pipeline, "vaguely inspired by" Basecamp's *Shape Up* (he found the book's examples "old-fashioned" but the ideas "really solid"). --- ## 5. Dan Shipper's Tooling and the "Bring Your Own Agent" Thesis - Dan spends his time in **Cursor** (~2–3 months), sometimes Claude desktop; his Claude usage tracks the availability of "Fable." - **Two-mode model of AI work:** - **Asynchronous delegation** in Slack (bots: Plus One, Victor, Claude tags) — collaborative, public, "you can delegate tasks as if it were a co-worker." - **Serious collaborative work** in shared surfaces (Codex, Claude desktop), because "you'll always get more out of it if you have a better collaboration service between you and the agent." - **Developer-patterns-spreading thesis:** "All the patterns that started with developers end up reaching all intellectual work." - **"Codex native applications" concept:** applications that "save state and render the interface, and you bring your own agent." - His reasoning: competing to build your own agent puts you against "the Claudes and Codexes of the world"; also "two agents are better than one." - Concrete examples: Codex handling a Verizon internet transfer in its embedded browser; an experimental email client ("Tend") where emails render as cards in Codex's built-in browser. - **Key technical requirement he articulates:** for shared human/agent interaction, the CLI/MCP must be able to **modify real-time interface state**, ideally with parity between UI actions and programmatic actions. - **Open question he raises:** how to represent agent presence and activity (analogous to Figma multiplayer cursors; Every's "Proof" markdown editor shows where Codex is in a document). --- ## 6. Chris Pedregal: Complex vs. Complicated Problems - Distinguishes **complicated** (understandable in advance) from **complex** (unknowable; must probe the system) problems: > "We're really deep into a complex problem space here... I don't have a general theory about where all this is going." - He frames his approach as collecting "nuggets of knowledge" he now considers true. ### "Time travel" problem - Agents take time; the moment a task starts and when its result is checked are **disconnected**. He predicts interfaces will evolve to optimize for this but says "I haven't seen anything that's great." ### Pre-generation and the "handrail" metaphor - **Claim:** pre-generating content beats waiting. Granola pre-generates "millions" of pre-meeting summaries (who you're meeting, prior context) even though only a small percentage (~10%) are opened, because the value comes "at the critical moment" — a ~15-second window when you're late to a meeting. - **Handrail metaphor:** Granola should be "invisible" like a staircase handrail — unnoticed until needed, then essential. - **Open measurement problem (he admits no solution):** low usage doesn't mean low value ("used infrequently but essential when used" is valuable); ideas considered include removal tests or forced click-to-generate tests, but "even that's not the best way." He acknowledges the cost tradeoff: "hundreds of thousands of hours of agents reasoning about things that may never see the light of day." --- ## 7. Granola's Strategy: Context Capture + Meetings - **Two-part strategy stated by Chris:** 1. "Be the best in the world at everything related to meetings." 2. "Be the best way to capture context to empower any agent you have." - **Context openness commitment:** Granola's context should be usable anywhere (Codex, personal agents) via API/MCP, which "is going to improve a lot in the coming months." - **Example he endorses:** a sales user generating client-adapted microsites with Claude, populated via Granola's MCP. Chris: "that's exactly the kind of thing we'd never try to be the best in the world at." - **Qualification:** he was "undecided about this two years ago" and only developed firm conviction slowly. - **His stated limitation/contrast:** "maybe you are more optimistic about AI than I am. I believe the models will continue to improve, but... if Granola focuses on a few things... tied to an interface that you have to use live during a meeting," it will win. ### Dan Shipper's complementary view - When he sees Granola's interface "it's usually a mistake — you don't want to see it"; he wants context extracted into Codex. - **"Bones and ligaments" analogy:** "AI is the ligaments and muscles, and the software has to be the bones" — AI is flexible only given proper structure and context. - He wants richer signal than transcripts (pauses, tone, nuance) — e.g., "there was a long pause after XYZ said this." - **Guinea pig thesis:** power users' workflows today presage what ordinary users get built into products later. ### Chris's disambiguation challenge (open problem) - Granola could build a running "two-page summary" of each user from accumulated context and use it to improve notes — but this creates a problem: notes could include inferences not from the meeting itself ("Dan doesn't really like that idea" based on past meetings). - **Unresolved questions he names:** who is the audience for notes (self vs. shared)? What "level of intelligence or interpretation" should Granola apply? He explicitly says Granola has the capability but doesn't use it yet. --- ## 8. Roadmap, New Interfaces, and Token Costs ### On model releases (Fable) affecting strategy - Chris's "order of operations": first how new models change internal building and team structure; the roadmap depends more on use cases "the intelligence of the model does not directly affect." - **Canonical interface gap:** he believes one or more needed user interfaces "haven't been invented yet" for manipulating large context sets (a week's meetings, messages, emails). "I don't think anyone has figured it out yet." - **His framing:** new UI paradigms are "discovered," not invented; chat threads are powerful for single tasks but lack "the right metaphor" for multiple contexts. ### Token spending - **Chris:** Granola wasn't tracking internal token spend until the week before the interview, prompted by someone spending "a couple of thousand dollars" in a day on Fable. He rejects token-spend quotas ("it's absurd to say that if you don't spend a certain amount of tokens, you're doing it wrong"). - **Dan:** Kieran (who leads Kora) was "on track to spend about a million dollars on credits in a year." - **Chris on product costs:** deliberately not cost-focused; philosophy is that costs will fall and can be optimized once the best experiences are known. **Qualification:** "Agent functions are really expensive. And as we create more and more, at some point that will break our numbers." ### Agentic usage statistic - **Chris:** "around half of Granola's users use us agentically" on a weekly basis (complex multi-step queries), while noting they likely wouldn't describe it that way. --- ## 9. Notable Tensions and Unresolved Items (preserved) - **Team size discrepancy:** host says ~55; Chris says 60–70. - **Chris's AI optimism vs. Dan's:** Chris positions himself as *less* optimistic about model capability than Dan, though both agree on context importance. - **Interface ownership tension:** Dan wants Granola invisible/background; Chris commits to meetings as a live interface Granola *should* own — neither fully reconciles this. - **Explicitly open questions both name:** role definitions without titles; metrics for proactive/pre-generated features; the undiscovered canonical interface for multi-context work; how much interpretation Granola should layer onto notes; measuring value of infrequently-but-critically used features. # Speaker & Provenance Record ## Video Identification - **Title:** Granola's Chris Pedregal on Building a $1.5B AI Company - **Video ID:** 01a0f15a-65f2-74f7-8eaa-86d8605c240b ## Speakers & Roles ### Chris Pedregal — Guest - Identified as **co-founder and CEO of Granola**, an AI meeting-notes app. - Previously founded **Socratic** (a startup of ~12 people, per his account). - Handles: his startup experience, Granola strategy ("knife fights," computer revolution framing), team structure, pre-generated meeting summaries, token spending philosophy. - Self-reported social handles (claimed, unverified): Granola's X/Twitter account **"meetgranola"** and his personal account **"CJ Pedregal"** (transcript spelling: "CJ Pedrical"/"CJ Pedrical"; spelling in transcript is inconsistent). ### Dan Shipper — Host / Interviewer - Identifies himself as "Dan"; guests address him as Dan; the closing promo names him as **"Dan Shipper as the captain of the spaceship"** of the show. - Associated with **Every** (see promotion below); references his own products: **Monologue**, **Kora** (email app), **Proof** (Markdown editor), **Tend** (open-source experiment he built). - Shares his own tooling and workflows (Cursor, Codex, Claude desktop) at the guest's prompting — dual host/participant role. ### Unnamed announcer — Narration / Ad reads - Delivers mid-roll ad reads, episode intro framing ("Chris, welcome to the program"), and closing subscribe pitch. ## Promotional Segments (flagged) 1. **Every subscription ad** (early mid-roll): "Every is the only subscription you need to stay ahead of the curve in AI... Visit every./subscribe/subscribe today." — promotes the host's own company. 2. **Adio (CRM) ad** (mid-episode): "Adio is the CRM for the agent-native world... Visit adio.com/every and get 15% off your first year." — sponsored ad with discount code; claims usage by Granola, Modal, WhisperFlow, and Every ("We use it internally at Every and we love it"). 3. **Closing subscribe pitch**: exhortation to like and subscribe to the show; names the show context as being about "ChatGPT" and names Dan Shipper; ends with an on-air comment of affection ("I am absolutely and desperately in love with you") — promotional/tone piece, not substantive content. ## Referenced Third Parties, Products & Sources - **Granola**: team size (~55, later "60–70" per Chris), $1.5B valuation (host's claim), pre-generates "millions" of meeting summaries (~10% opened, per Chris). - **Anthropic / Claude**: Claude "Tag" (transcript garbling of a Claude release), Claude Code → "Claude Co-work," Claude desktop app, "Fable" (a removed/limited Claude feature both speakers reference; Dan had prior access). - **OpenAI**: Codex (used heavily by Dan, including "Codex-native apps" concept and built-in browser workflows); OpenAI reportedly launched a Granola-inspired feature (Chris's claim). - **Slack agents**: Every's **Plus One**, **Victor** (named by Dan as internal/third-party bots). - **Notion, Zoom**: cited by Chris as having launched Granola-inspired meeting-notes features. - **Basecamp**: book *Shape Up* (referred to via garbled transcript as "the form"/"Ryan's... the guys from Basecamp"), influencing Every's shaping/validation staging. - **Hugging Face**: Chris recounts an unnamed founder there abandoning a Claude Code workflow in favor of Granola. - **Verizon**: example of a Codex-driven customer-service interaction (Dan's apartment move). - **Other tools named**: Cursor, Figma (presence metaphor), Google Docs, MCP, Kora, Proof, Tend, Socratic, Whisper/WhisperFlow, Modal. - **Named third individuals**: Kieran (directs Kora, per Dan), Ryan (Basecamp reference), "Sam" (brief disambiguation example, uncontextualized), an unnamed sales user of Granola + Claude microsites. ## Comment Availability - No information about comments is present in the transcript or metadata. **Unknown.** ## Provenance Notes & Uncertainties - Transcript is machine-garbled in places: "Claude Tag," "Codeex/Codecs/Codex" spelling variants, "every./subscribe/subscribe," "Adio," "Pedrical" — original proper nouns inferred but not confirmed. - No curated metadata beyond title was supplied; speaker identities rest on in-transcript statements. - Prior conversation between host and guest referenced ("a very good chat in December 2024") — dated claim by host; noted as stated, not verified. - Timestamps are not present in the transcript; no time positions can be recorded. You are co-founder and CEO of Granola, one of the first AI apps where people say, "Wow, this actually works." Meeting notes are not the ultimate goal that everyone is pursuing. There is something much bigger. And I believe we are in the initial stages of a computer revolution. What has come so far will pale in comparison to what is coming soon. Startups are like knife fights, and I thought they were only difficult when they weren't working. It turns out that they are also very difficult when they do work. Every is the only subscription you need to stay ahead of the curve in AI. If you care about staying up to date with the latest models and using new tools, you should subscribe to Every. We'll help you separate what's important from the noise. Visit every./subscribe/subscribe today. And now, let's get back to the episode. Chris, welcome to the program. Hi Dan, it's great to see you. Likewise, it's great to see you. It's been a while. For those who don't know you, you are the co-founder and CEO of Granola, one of my favorite AI apps. One of the applications that I think really started the AI ​​wave about two or three years ago. It was one of the first AI applications where people said, "Wow, this actually works and it's useful." And since then, I think the team has grown to about 55 people. You have raised funds with a valuation of $1.5 billion . They're doing incredibly well. We had a very good chat in December 2024, two and a half years ago , about putting soul into your product and creating things that are charming. I'm very curious to know what you have in mind, how things are going, to share our paths and reflect on the future. I couldn't be more excited to chat. I've been following all the things you've done from a distance. So I'd love to hear the latest from the inside about how everything is going. Just to react to something you said, you mentioned that "we're doing incredibly well," right? We are very fortunate and things are going well. But something I wasn't prepared for, and I've already done a startup before, is that startups are knife fights. It's like, really, you know, it's like , well, I don't know, maybe, maybe life is easy for you, but for me, it's like, it's really hard, and I thought startups were only hard when they didn't work. It turns out that they're also really difficult when they actually work. It's simply a knife fight when things are going well and when they're not. And I was a little unprepared for that. So, uh, just, um, I'm, I'm really, I had a professor in journalism school who, um, basically said, "The last thing the world needs is another profile that glorifies someone," you know? It's like, "Oh, this person is so cool." And it's like, no, no, it's all a difficult struggle day after day. That's it , that's my mindset. So, I just wanted to share that. I understand you, friend. Um, I definitely feel the same way; I've been building companies for a long time and this is the first one that's actually growing and functioning in a way that feels like a real business. We're already 30 people, you know. Um, and thank you. And when it's working, as a good example, Claude Tag came out yesterday. We've been working on a Slack agent. Claude Tag came out yesterday, and then everyone looks at you like, "What do we do?" And I say, "We are, we are prepared for this. Uh, we've been thinking, we knew this was going to happen." And, especially in AI, I feel like the terrain is changing so fast, and I guess for you, one of the things you're talking about, and that I'm talking about, and I'm actually very curious about, is that you were the first to do really cool AI meeting notes and transcripts, and then, right away, everyone just added meeting notes to their products. In fact, we have this product called Monologue that has a meeting notes button, you know? Oh excellent. I didn't know. So, we're kind of... Yes. No, I don't really think it's an exact one-to-one replacement. Actually, I have both on my computer, but anyway, that's probably what you mean when you say knife fight. So, tell me, tell me about that. How so? How has that actually affected your business in any way? Actually, that's not what I meant by a knife. I mean, it's part of it, you know. Um, I think it's just , uh, I guess what I meant was, um... I think, by definition, a startup is, you know, either you're fighting to survive. It's like you're always fighting to survive, and if things go well, it's like you 're on a big wave on a surfboard, desperately trying not to fall off. And therefore, you are always right at the limit of your capabilities. And, um, it's almost as if, by definition, I'm always doing, you know, this is always being heard. It's like, oh, as a founder, you're always doing things you do n't know how to do. It's like, oh yeah, actually, at least that's been my experience. I'm always in that space where I do things I've never done before or that are more than what we've previously attempted. Um, yes, the competition. Look, this is my opinion and I feel like I've already said it. Um, let me think about it. I think when I think about this, it's going to sound like one of those absurd answers about competition, right? Because there's always that interview where they ask : "Hey, Microsoft just copied your product." So, you know, how do you feel about it? And the founder has to come up with some kind of response. The way I see it is that I think we're in the very, very early stages of a computer revolution and that, um, there's...what's come so far will seem insignificant compared to what's coming soon. And I don't think it's as if meeting notes are the ultimate value that everyone is looking for. There is something much bigger, and I think it's what interface we use to work and how we work, and what that looks like in an AI-native world; So, when I think about competition, I feel like what people are fighting for today doesn't matter. There's an incredible opportunity ahead, and I think we have a chance, just like a few other companies, right? But, well, that's really what matters. So, in the same way that people say, "Oh, Granola is doing really well." It's like, well, in my opinion, it's like what comes easily, goes easily, right? Look, meeting notes are useful, but many things are going to change in the future. And just because people use us today, doesn't mean they'll use us for that in the future if we're not the best at what comes next. So , yes, I know that's my general perspective: people...and the other thing to say is that we weren't the first to take notes in meetings, right? In other words , AI note-taking assistants have been around for a long time. We, let's say, were very inspired by things that already existed, so I can't say, "Oh, how dare you be inspired by what we did?" You know, it's just part of an ecosystem. The truth is that it has affected us much less than I thought; For example, Notion copied us or whatever. Let's just say they're launching something that I think is very much inspired by Granola. OpenAI did it, Zoom did it recently. So, in a way, I didn't have to face the nightmare of thinking about what would happen on the day it was launched; It just happened and we're... still here. Yes. Yes. We're still here, nothing has changed in our growth rate, but again, we're still a drop in the ocean compared to what we'd like to be. So I think it's just the beginning, that's my opinion. That makes sense. I have to say that I love talking to you because I feel like you're very honest about what you're facing. It's the best. It's a lot of fun. It's very, very different. He's very different from many people, and I think this will be a very fun conversation. But what I want to get back to is...and I also like to share it. I want to go back to what you said, that you 're on the surfboard trying not to fall off. And you know, usually in startups, you're on the surfboard paddling and waiting for the wave. And I think for both of us, more for you than for me, but for both of us, it's like we're riding a big wave right now. Let's try not to fall and get beaten up, okay? Okay, so what are some recent things where you've felt like you were at your limit and you're like, 'I have to figure this out'? I need to resolve this. It is, maybe it's a good thing, but overall it's like, damn, this is very different. So, a lot of it has to do with my limitations or my lack of experience as a founder. For example, in my last startup, Socratic, there were 12 of us. So going from 12 to, well , now we're between 60 and 70 people. And, you know, that's very different and I've never done it before, right? And then, organizing people, that's one. Something that is challenging, and I wish I had a concise and elegant answer like we already have it all figured out, but in an era where you talk about the product having soul, feeling consistent, coherent and tasteful, how do you scale that when you have more people working on it? How can you gain the advantage of having many people working on difficult problems, while maintaining that sense of coherence? It's a very complex problem. I think there are so many interesting topics we could explore further. But one is the traditional roles of product management, design, and engineering— how you group those people and what their responsibilities are. I feel that what worked in the past might not make the same sense in the future, but I really don't know how to define roles and divide the work. It's valuable when you say, "You're the designer, I'm the engineer," or vice versa, because that way we know where we collaborate and where the dividing line is. Do you have a philosophy on this at Every o? I do n't know, we've done different things and it depends a bit on the product situation. A mental model that I have and that seems to work, especially for initial products, is that there are two roles that matter: one is called the pirate and the other is called the architect . The pirate's job is simply to build as quickly as possible to find something valuable. And it can be programmed by intuition. You don't really have to think about architecture , or all that kind of stuff. And the architect's job is to partner with the pirate and think, as the pirate finds something valuable, about how to turn it into a sustainable system that we understand and that can scale. And the interesting thing is that I think you need one pirate per product, but you can have one architect working on several products. You can make them jump from one to the other because the current tools are so good that someone who is an excellent programmer, an excellent architect, can simply go into a codebase and say, "I'm going to learn this codebase in an hour because I have Claude or Codex or whatever to map it to me, and then I'll identify the structural pillars, the invariants that must be met for this product to work well, and then I'll ask Codex to do a 24-hour rewrite, and then I'll go do something else." And I think that's really interesting. That's one division, and in particular, the pirate is this mix of technical product design, all of that together, and the architect is really focused almost exclusively on the technical side of things, but honestly then they don't have independent designers, right? Yes, we do have independent designers . Once it becomes something like a real product that we're going to support, then yes, we have independent design. We have a design team that goes to each product and helps improve it. But on the technical side, for example, we have this Slack agent that we've been building called Plus One, and they're just a group of engineers who are all working together and are, to some extent, full-stack thinkers, but it's very focused on engineering. So there is no single answer. I have n't fully deciphered it yet. I think the pirate and architect setup for new things is very useful. But what are you doing? Yes. Well, we have something similar, but it's not really role-playing. So, for any kind of new feature, we have this idea of ​​stages. So, the first stage is like the setup. So, it is, it is, um, and we are influenced by the, uh, what is the form. Yes, thanks. Um, yeah, Ryan's, right? Yes it is? Yes, I think so. Yes. Like the guys from Basecamp. Um, it's kind of vaguely inspired by that. I went back and read it, um, or at least the first half which was about that. And, um, it's funny, it felt, it felt very, uh, old-fashioned and, uh, much more old-fashioned, like, because of the functions they use as examples, for example, the ones they talk about building, um. But some of the ideas, I think, are really solid. So we have this idea that there's like a shaping phase where what you want there is that you want to, you want to, um, explore as many potential solutions as possible. So you start with, like, a job to be done, like, "Here's a user need, here's the job that...here's a job we'd like the user to hire us to do," right? And it's like, "Okay, this is the job. What are the possible forms of that solution?" And you go and explore those ways as fast as you can. And then , you look at that, and you have to be really honest with yourself and say, "If we dedicated time to this, do we really think we could...like, would people actually hire us to do this or not?" Right? And then, and then we have a next phase which is, like, validating. It's like, "Okay, we think we can, like, try... like, for a small...a small number of people, like, just try to prove that you can be useful and that they choose to use you." And then it's like, if you ...if you...if you can prove that, then it's like, "Okay, let's make this really good and...and reliable and scalable and all that." It still doesn't answer the question of, like, who...the...what are the roles of the people who work on it, you know? And...and, um, yes. But hey , it's just one of those open questions. I mean, you have, you know, 60 or 70 people, so you've had to respond to that at least provisionally, so what's the structure you've provisionally arrived at? Uh, we're still, we're still experimenting with that. It's like we still have, uh, titles and I don't know if we should have them. So, we have, you know, you're a designer, you're a PM , you're an engineer, right? And I'm always, always flirting with the idea of ​​eliminating them. How many count? Uh, four. Three, it depends, it depends if you count me . Yes. Yes. Three. Not me , I wouldn't tell you. Yes. Yes. Okay. Yes. Yes. So three. Yes. Interesting. Yes. And, well, I've always flirted with the idea of ​​eliminating them because what you really want is for someone to do certain things on this project. Like, someone needs to take care of the aesthetics or user experience and someone else needs to take care of the construction, and it could be the same person or two different people, right? And someone needs to take charge of what we're trying to do here, what the strategy is, and what the next steps are to achieve it. But then, there's a lot of communication involved if you don't have roles, right? It's like: " Okay, what exactly are you going to do in response to what I'm going to do ?" Maybe one day they'll all be agents, who knows? We will continue, we will continue, we will continue experimenting. Interesting. Well, one of the things you said right before we started recording is that you spend most of your time in Granola. And one of the things that makes you curious about me is what I'm discovering by playing and experimenting. So come on, let's talk about it. I think there's a lot of material there. First, tell me about that, about how you spend most of your time in Granola. I think it makes a lot of sense, but also, as a CEO, it's a strategic way of being. Tell me about that decision. Well, I mentioned earlier that I think the big opportunity here is to invent how we're going to work and collaborate with AI to think and do things, right? One way or another, that's what it is . I think that's what we're all chasing right now in Silicon Valley, isn't it? And, uh, to that end, I think there's a lot of, uh, that's the kind of stuff you can think about abstractly, but then you have to play with it to, uh, get an idea. And, uh, it's just hard for me to have the mental space to play with every new thing that comes up, right? And at Granola , we have a lot of context and many internal tools so you can play with different ideas, but they're often kind of in my own little universe. Unlike, for example, I do n't go and set up very complicated workflows in Claude; I do it, I play around with it to get an idea, but no, they're not fundamental to me because I'm trying to see what makes sense or what doesn't make sense to do within Granola while we paint that picture of the future. It seems you're at the forefront of experimentation, trying new things and creating different workflows for yourself. So, perhaps, let's start by finding out the current state of Dan's tools and then we can go from there. I spend all my time on Cursor. Alright . Almost. How long has this been going on? Is it recent? Like two months ago? Maybe two or three months. Alright . Oh, and then I also use Claude's desktop application sometimes. Like when Fable existed, I track all my usage, and when Fable was around, you can see how my Claude usage increased, and then when it was gone, it just dropped. Uh, so I guess when I come back, because I think Fable is just a different beast and I try out all the new stuff and have access to things before they come out, and Fable is just different. Um, but I think my overall view is that the work is branching out into two areas. One is the asynchronous delegation work that occurs in Slack. That's collaborative, multiplayer, uh, sometimes proactive, and it happens with Slack bots, like we have one called Plus One, there's one called Victor, there's Claude's tag, and that's very much like, uh, okay, every morning he posts to our channel and says, "Hey, here are all the bugs that were fixed." Here are all the errors that were reported. Here are all the public relations materials we sent. Uh, and then you can tag it and say, " Can you, you know, start, can you start a public relationship for, you know, the XYZ bug?" And it simply does. Or can you, uh...we're trying to name this new product? Can you read everything we've said about what we want the product to be and suggest some names? And that way the team can be exchanging ideas on the same channel to talk about names. This way you can delegate tasks as if it were a co-worker. And most importantly, since most of today's AI is individual, you can do it in public. And I think that's very interesting in a whole range of ways. However, for serious work, you can't... you'll always get more out of it if you have a better collaboration service between you and the agent, and Slack isn't good for that. So the other surface is something like Codeex or a Claude desktop application , where you and the agent are in the same place, in the same application. And in Codeex in particular, for me it's as if I use almost all my software in Codeex's built-in browser. So I carry Codeex to my email or whatever, in the same way that... What do you mean by that? Can you describe it? How do you do that? Yes, I'll explain it to you. You know, when you build something in Codeex or Claude Code and an integrated browser opens up that lets you see the local version of what you 're iterating on. Basically, all the patterns, a good mental model of how AI works for me is that all the patterns that started with developers end up reaching all intellectual work. Because what we discovered is that building an agent good enough to do any kind of software, once it can do that, is really good for any intellectual work you want. And that's why Claude Code became Claude Co-work, and why Codeex is all about intellectual work and that kind of thing. So, one of those patterns is that when you build an application, what you really want is for the agent to be in the process with you. So, while it's building something, open an integrated browser, you can see it and go back and forth with the changes. You can make notes, whatever, and you and the agent are looking at it together. That pattern also works for any type of software. So, any type of website you might visit. So, a very simple example. Um, last night, uh, I recently moved apartments and needed to change my internet, so I just told Codeex, "You sort it out." And he knows the address of my old and my new apartment, which is actually the same building. I'm just moving apartments. He simply opened the Verizon website in his built-in browser and logged in. I gave him the password. You are logged in. I gave him the password and then he opened a chat with a customer service agent, who was probably also using AI , and just chatted with him until he changed my internet. And also, all these little things come up, like, okay, when do you want to move out and when do you want to leave? And Codeex knows this because I've been talking to him about when I moved and when I wanted to make the change. Um, and then it's like, here it is, your previous plan no longer works. Here's the new plan. Um , and Codex knows he should say, "I don't want any hidden charges." He knows how to do the math on, you know, is this a good deal or not? And he's able to investigate it and then pressure them to give me what he thinks I should get. And I don't have to do any of that. I just sit there. And is that something you communicated to Codeex in some way, or is it something that's already integrated? Obviously, any human would want this when talking to an internet provider. It is, it is both things. It's easy because it's easy for him. He knows very well when he can make assumptions and when he shouldn't. Um, so I can keep up with everything and I can also just go to another thread and be doing something else. So I'm kind of switching back and forth with him. I think that's something, but there's something more general there, where I use, this is how I handle my email. Um, stay in touch with me on Kora, which is our email app. And, um, I also have this, this, this open-source thing, an experiment I built called Tend. But basically it's as if my emails are now cards that I read in Codeex in the built-in browser , and then each card says, "This is what the email said." "This is what I think the draft should be." "Do you want to send it?" And I simply talk to him. I see. So, basically, you programmed your own email client by instinct, right? Is that it? I instinctively programmed an experimental email client that does this, and then we'll have a version of Kora, which is our full email client , that will include it by default. But you can think of applications structured this way as... I've been calling them Codeex native applications , but basically they're applications responsible for saving state and rendering the interface, and you bring your own agent. And I think that's a much more powerful paradigm. Because think of all the work you have to do to make Granola have a good agent, it's really difficult, and you're also competing with the Claudes and Codeexes of the world who are also creating the same type of agent with the same functionality. And, to a certain extent, I also believe that in some cases it's well worth it, because I think two agents are better than one. But ultimately, I really want to be able to, for example, bring...and I think you're probably seeing this with a lot of Granola users. I really want to bring my agent to Granola. You already know how AI is changing the way daily work is done, how much ground you can cover, and how quickly a team can grow. To stay ahead of the curve, you need tools that give you a competitive edge, designed for this new era. Adio is the CRM for the agent-native world. It accompanies you wherever you work, combines every customer signal in context, and then acts on your sales pipeline to enable you to move forward at unmatched speed and scale with agents and automations for every task. Adio organizes your work throughout the day. We use it internally at Every and we love it. It's designed to handle the scale of your workloads. It is extensible with API and MCP access, and has an infrastructure capable of keeping up with your most ambitious agents. It is loved by high-growth startups like Granola, Modal , Whisper Flow, and Every. Adio drives the work behind every victory. That 's Adio, the Agentil CRM. Visit adio.com/every and get 15% off your first year. It's adio.com/every. And now, let's get back to the episode. What do you think? Yes, you keep saying that and I'm really excited about that idea. I wonder, how does that work in practice? I mean, forget the granola, but, you know, let's say you... I don't know, can you do this with Kora right now? Or, how...how do you build an...how could we build an application that allows you to bring in your own agent that isn't, you know, MCP, because it feels a little different, doesn't it? Because it's like you still want the user interface, that's the difference. It's as if you and the agent were seeing the same interface and manipulating the same thing. MCP is part of it. Um, but yes, I think MCP historically is thought of as the agent interacting with the application and not me. And I think what this paradigm says is that, in reality , you want your agent and the user to interact with the application at the same time and be able to take turns. And the way to do it is, yes, you give the agent access to an MCP or a CLI. Um, and then you give the user access to a web interface, and the user uses the web interface within an embedded browser of a codeex, or a code cloud, and the agent can decide: "Do I want to help the user or collaborate with them using the browser or the CLI?" Which I think the CLI is somewhat better, but the trick is that the CLI has to modify the interface state, right? Exact. That's the key point. It's as if that's what it needs to be. So, it's almost like you would , hypothetically, let's say you could have an MCP, right? That it actually had a state, like the MCP could modify the state, the real-time state, of a rendered interface for a user, and ideally there would be at least a one-to-one correspondence where whatever you do in the interface can also be done through the MCP. So you have an agent and a human interacting because, um, using a computer or a web browser feels unnecessarily slow, right? It's like a patch, uh, no, no, yes. Well, that's very interesting. Um. Yes, there is something about the agent's presence, I mean, this is a fascinating topic. I haven't thought about it much, but the agent's portrayal might also be interesting. You know, it's like, you know, when you're in Figma, you can see other people, uh, like their locations on the canvas, and there's, there's something there that might be lost if there was only one MCP and the human, maybe, maybe not. I don't know how you feel. Do you feel like the agent is just the computer and you know that everything is the same, or does it feel like an entity with which, you know, you're both seeing the same thing together? Furthermore, it's the same way as with a Google Doc; we have this Markdown editor called Proof that we built, and in that you can see that Codex has entered the document and you can see where it is. Oh, that's great. How do you do that? How, how does Codex get into the document? It's just the same kind of CLI MCP situation, but it has a command that's like "ok, set presence", "set location in document", that kind of thing. And the agents are very good at knowing how to do that. But there are so many interesting interface challenges to solve, because an agent can do like a thousand different actions at once. So how do you show that to a user? It's interesting. That's not really where my mind went, because you're right. It's like, yeah, it's like , if you want to see what the agent is doing, that's a problem; I was just thinking about something like an email. It would be good if I knew where your mouse is. It would be nice to be able to just circle it and say, "Ah, this part of the email isn't very good," and make that, you know, highlight the text or something . And that's not really possible today unless explicitly, how would you have to do it? I'd have to be looking at the pixels on your screen, right? There's no native way to do that unless you integrate it into an interface and are passing that information to the agent, right? More or less. I think the way I do it is that each piece of information I want to deal with is represented on a card, and then I can talk to the card. I can say, uh, yes, it doesn't necessarily know where my mouse is, but it knows that I'm talking to this part of the interface, and so it knows it simply because you say so when you talk to it, or because it's the main thing that's in the foreground in the application. Whatever he's looking at is in focus at that moment, so I know he's focused and when I talk to him, he just knows how to put that context alongside what I'm seeing. Okay , that makes sense. And this is, you 're really talking, right? It's like you're using Monologue or Whisper or something, right? Yes. That's more or less my view of the work and how things are going, and we've been talking about how, okay, the reward is that there's a new way of working. How does that fit in or differ from what you've been thinking about and your strategy for Granola? Do n't know. I took a class once and they talked about the difference between complex and complicated problems . Have you heard about this? Yes. Yes. And it's like, uh, complicated doesn't mean it's super difficult, but rather that it's something you can understand, you know? It's as if you...and complex problems are unknowable. You have to probe the system and see how it reacts and start from there. And, uh, so I think we're really deep into a complex problem space here. So I don't have a general theory about where all this is going. I think I could come up with one that would sound plausible, or as plausible as anyone else's, but I'm more in the mode of: what are the ideas or nuggets of knowledge that I say, "Okay , this is something I've learned and now consider to be true, and I'm going to take it with me"? Uh, so I have some of those. For example, one seems to be that a fundamental design challenge in the world of agents is the problem of time travel. Basically, the agents take time to do things. And so, when you were talking about Slack as an interface for this, which is like the asynchronous delegation problem you mentioned earlier, it's basically that the time you start a task and the time you check it are disconnected, and so you need to put all that context into your head and... I think that will be one of... I think we'll see many, uh, interfaces that will evolve to be highly optimized for that. And to be honest, I haven't seen anything that's great. It's like, I don't know, like the driver, it's like "ah, I have all these different chat threads and I jump between them when it's ready," it feels like there will be, I don't know what they'll look like, there will be evolutions, you know, beyond that that are coming. Um, another thing that has been, which is interesting, as another way to avoid this, as the problem of "it takes time for an agent to do something", is, uh, to preprocess a lot of things. Yes, yes , like, uh, for example Granola, one thing we discovered is that if I ask Granola to do something and I have to wait 20 seconds, basically humans rarely wait 20 seconds if they are in continuous meetings, in a chaotic and crazy workday, which is more or less the type of user we have in mind . But if Granola thinks of something you might want and then pre-generates it, and at some point says, " Oh, here you go if you want it, it 's ready and you just have to click." That feels completely different. And then, we have some examples there, like, we recently launched this where Granola tries to generate a summary for you before a meeting, where it basically tells you who the person you're going to meet is. Here is the context of who the person is if it is the first meeting, or what they talked about last time if it is a recurring meeting. And you essentially have to pre-generate this because it's useful when you're 2 minutes late to a meeting and you're thinking, "Wait, who the heck is this person I'm talking to again? " It's like, and that's the critical moment . So you really only have a 15-second window where it needs to be there or it's basically useless. So, in fact, we pre-generate millions of these, an absurd amount , even though only a small percentage will be opened, with the conviction that when you do open it, you really appreciate it because it's exactly what you need at the right time. It's an interesting process or exchange, especially from a cost perspective, because, you know, it's hundreds of thousands of hours of agents reasoning about things that may never see the light of day. And how do you measure whether that's really worth it or not? It's an open question. I still don't quite know how to measure it. What I'm trying to figure out is that we don't have a good metric for that. There is the use. If something isn't used at all, it 's obviously not good, right? But what if something is used infrequently or in decent amounts, but is essential when used? That is still very valuable. I'm trying to figure out how to measure that, you know? I was at a founders' conference the other day and four of them approached me to talk about this summary function, which surprised me because it's not used as much as I would have expected. So, yes, we have this analogy, or metaphor— I always forget which one it is—within Granola, about how we want the product to feel. It's like a handrail. If you imagine a staircase, they all have handrails, right? And basically, you never notice the handrail. It's like invisible, but the moment you trip, your hand flies off; it needs to be there, it needs to be strong, and it makes stairs much safer. And that's how we think about Granola, you know? We want to get out of your way until you really need us. But yes, we probably need better metrics or frameworks to measure it. One thing we thought about is, what if we remove it for multiple users? How much would they complain, or what would the impact be? But even that's not the best way. Or maybe do something like see if they 'll click to generate, like click to generate instead of just saying it's already generated, but you know, would you take the proactive action to do it? to do it and then it's there. Yes. Yes. But once it's done, will we always force them to click? Don't know. It's like, we could do it as a test. I suppose it is, it is, it is, yes, it's a complicated issue. That's complicated. That? Um, well then, h-how...so how do you also think, what is Granola's role compared to Codeex and Co-works around the world? And what do you see as places where you want to integrate and be available for what they do, versus places where you say, "I want to own this"? This is something we can do exceptionally well. Yes. So my take here is that, um, it's like a new era, it's like this new age of computing where, for the first time, computers can understand our context and you can do amazing things with that, right? And, um, and to that end, having the right context is really critical so that you can get value from AI. So my belief is that the context you have in Granola should be made available in the way you want to use it. So, if you want to use it in Codeex, if you want to use it in your personal agent, if you want to use it for whatever , you can do so; If using Granola in context makes your life better, you should be able to, and we should make it easier. And, um, there's a lot, you know, our API or MCP is going to improve a lot in the coming months because that's one of our main goals. Um, I think there are a number of tasks to be done, pain points, use cases where we should simply be 5 times better than anyone else in the world. And, um, and those obvious ones are all related to meetings, right? It's just one of those things where, and maybe, just maybe, you think differently. Perhaps you are more optimistic about AI than I am. Like me, I believe the models will continue to improve, but I think that, uh, if Granola focuses on a few things much more than anyone else and we optimize them to the fullest, they will simply offer a better experience, especially if they are tied to an interface that you have to use live, during a meeting, for example. And that's basically our current strategy: to be the best in the world at everything related to meetings and to be the best way to capture context to empower any agent you have. And that sounds good, I can give you an example. I was talking to a user and she was doing something really ingenious. She worked in sales and basically used, I think, Claude, to generate a microsite before talking to a potential client, and the microsite was really impressive. They had a template of what that microsite would look like, and when they had a new potential client, Claude would adapt that template to resemble the client's website. Then they connected the Granola MCP to extract all the Granola context and populate all the data, fields, and widgets based on that information. That's exactly the kind of thing we'd never try to be the best in the world at, and it wouldn't make sense, right? But in her case, she wrote many emails in Granola right after meetings, because she found the follow-up emails in Granola very useful. And that's the kind of thing we might not want to write in every email. We don't want to be your inbox, but there might be a type of email you want to send right after a meeting that's extremely good in certain aspects, in which we might be the best in the world. And it makes sense to do both. I don't think it's one thing or the other. I was undecided about this two years ago, when we started Granola. Now I have a firm conviction, but it took me a while to understand it. That's interesting. Yes. I think that from the user's perspective , and perhaps not as the primary user, I find it very interesting to learn that because one of the theses we develop in each round, and one of my convictions, is what creators are doing now. The people who want to decipher these general-purpose tools and build these workflows are what ordinary people will be doing in a few years, once it's integrated into the structure of these products. So what I do is experiment with things and try to figure out what I use Codecs, Slack agents, or whatever for, and eventually it will come down to what we build, what labs do, or what others create, and we get to see it first . Can I ask a question about this ? Because I think, um, the theory is that the things you try to automate with AI, or the interactions you seek to build, you think others will also create their own automations, less focused on AI , or do you think that will become a product? And yes, okay, I have the same opinion. So, I guess you guys are the guinea pigs, right? Basically yes, and we have a lot of guinea pigs using Granola. TRUE. My view is that we should simply look at the most common and advanced ways in which people use our API and MCP to do amazing things. And then determine which of those we believe we could be the best in the world in, and which many users would benefit from. And to build a truly beautiful and seamless product experience, which may have taken time; The other day I ran into one of the founders of Hugging Face at a conference and he said to me, "Man, I built an incredibly complex workflow in Cloud Code, worked on it for months and shut it down because yours was better." You know, and for me that was exactly what I wanted. Although we can't do this for everything. But that's exactly what I want because it's going to matter to us more than anyone should; the workflow is pretty much as I envision it. I think that's absolutely correct. Okay . So, we're definitely aligned on that. My current feeling is that in general when I see Granola, and this is just my opinion and it could change, like when the interface appears, it's usually a mistake. You don't want to see it. I don't want to see it. I mean, it's fine. The recording thing is fine, but in general, the way I want to access it is either by sending something to Codeex, which is my workspace, or by having Codeex extract something from there. And I think this approach to meetings is very accurate, and it's such a deep and difficult problem to get the context right. For example, you know this better than I do, but I think about when we do a transcription and I say the name Chris, which Chris are we talking about, right? And so, I think about the work of software companies in an AI world. AI is very flexible, but only if it is given the right structure and context within which to be flexible. If we use the human body as an analogy, AI is the ligaments and muscles, and the software has to be the bones. And the bones give it shape and structure, but then the AI ​​can work around that to do anything. And there's a lot...even, for example, in the transcript of a meeting I might say "It's a good idea, " but the way I say it reveals a lot of what I really think and it's not captured just in the transcript. And I want Granola to be, uh, I have this automation that turns all the Slack messages and all the meetings I didn't attend into cards. I review them to see what happened at the company, but the transcripts are often inaccurate and don't capture any of the nuances about how and why things were said. And I think if Granola did that for me, it would be the most valuable thing in the world and I wouldn't necessarily have to look at the product. And maybe, perhaps for a more common user who doesn't want to be dealing with codecs all the time, although I do think that's going to become more and more common. In other words, you still want to have the interface, but there's all this background context processing that I would expect you to do that I really don't want to do. Yes. Yes. Yes. No, that makes perfect sense. I think, uh, I suppose that transcription is a way of capturing the context of a meeting, right? It's the simplest way , and language models are surprisingly good at making sense of confusing transcripts and doing something useful with them. Uh, I think so, but what's the real work that needs to be done here? The real question is, what are the ideas, decisions, or actions I should take based on this context? And there's this layer of, uh, intelligence or interpretation, which is like disambiguation, what Sam did, I mean, is a great example. Uh, we have this, uh, so we have this, uh, I'll give you an example, there are challenges, it's a very interesting space. So, here's a challenge we have, right? Uh, we, if you, when a user starts using Granola, they use Granola a lot, right? And therefore, we have a lot of context about that user, right? And we can, in the background, and we have this, but we do n't use it yet, and I'll explain why, generate a fairly accurate picture of who you are, what you work on, what you're trying to achieve, what your challenges are, and who you work with on different things. And let's assume, for the purposes of this discussion, that it's a two-page summary of who Dan is today, right? Dan's current condition today. And it changes every day. And we can generate better notes if we pass on that context as part of our note-writing process . Uh, but now those notes could include information that didn't come from the meeting, right? So when you said that, it's like, "Oh, that's interesting." Or, "What was your example?" It's like, "Oh, I like that idea." And we might think, "Dan doesn't really like that idea. He thinks it 's a terrible idea." Because we know he hates those kinds of ideas, since he said so five other times in five other meetings. And then this interesting question arises of, well, who is the audience, right? And nowadays, many people still use notes for themselves, but there's also this mixed use, and we share them with others, right? Uh, although the perfect notes for you are probably a little different, or the perfect notes are just one...uh , it's just a way of representing that information, you know? There are other ways , and it's like, what level of intelligence or interpretation do you want Granola to perform? But yes, I understand you perfectly. That's why I think we're either still in diapers or, honestly, you seemed very stressed in that meeting . Do you want to talk about it? That would be very, very interesting. Perhaps people would be scared by that. But also, one of the things I use Granola for a lot is for management issues , and thinking: "How did I do there?". Or if someone on my team had a difficult conversation with someone on their team and tells me about it, I say, " Let's talk to Claude about the meeting transcript to decide what to do." All that kind of stuff, to do it right, I don't just need the transcript, but there was a long pause after XYZ said this. Nobody said anything for three minutes; That's not shown in the transcript. Um, no. Yes. Things like that, there's so much richness there that I want Granola to do for me. Yes, that makes perfect sense . Yes, I also think so... I'm curious, what is the main form? Because you say, "I don't want to see the Granola interface." "I want to take it to Codeex or something like that." And I also wonder, okay, what are the main workflows or reasons why people bring transcripts or meeting notes to their agents? And if you had to optimize, which ones would you do best? And what are the exceptional cases, such as: "Give people power and they will do a better job," which is also an interesting question for us. Yes. What do you have in mind for the next six to twelve months, now that, well, you saw Fable come out? Does that affect your roadmap or how you hire and build? Tell me about that. The order of operations, the questions that go through my mind are first: how does this change the way we build internally and how we structure our teams? That's the first question. I think our roadmap is...and this is the kind of thing where, you know, you can plan in the abstract and then, when experimenting with something, you have to adjust it. And unfortunately I didn't get to try Fable enough before they removed it. But the roadmap is already a bit more integrated, in the sense that the models are simply going to improve. This is the overall strategic direction , and I believe our strategy depends more on what people use it for and what jobs need to be done or what use cases we can address; The intelligence of the model does not directly affect that. If that makes sense. While the model's capabilities do affect how many people we assign to a team, you know, how do we define the goals there? Should we be approaching things in a completely different way? So yes, that's something I have in mind, for sure. The other thing is that I...I think...maybe this touches a little on the topic of what you use for codecs. I think there's something... I think there are one or more canonical user interfaces that haven't been invented yet and are needed right now. For example, in Granola you have meeting notes, right? And you can use meeting notes, transcripts, or context for many things. Generally, when you try to use that context...it's not because of a meeting. You usually have a context set. In our case, let's say it's all the meetings you had today or all week. And maybe it's all the meetings, Slack messages, and emails. But let's just stay in meetings for a second. At that level, what is the appropriate user interface and interaction design to manipulate or work with that context? I don't think anyone has figured it out yet. And maybe, just maybe, you're working on something, Dan, or maybe you'll manage to figure it out. But when I look around, I feel like I've seen very little, to be honest . And you know, creating new user interface paradigms is very difficult and it's rare for any of them to last. I think that rather than inventing them, they are discovered, if that makes sense. But I see a very clear gap in that respect. We have chat interfaces, and chat threads are super valuable, surprisingly versatile and powerful for a single task, but when trying to do multiple things in different contexts, I don't think we have the right metaphor. So it's something I'm very aware of. Because when thinking about the average user, I believe they will need a simple metaphor that they can easily understand and interact with. It won't be the kind of obstacles one currently has to overcome with codecs. Yes. How do you approach token spending both on your team and in the product? I think...well, I'll talk about the team first. Regarding token spending on the team, I think everyone should use AI to enhance their capabilities as much as possible. I think it's absurd to say that if you don't spend a certain amount of tokens, you're doing it wrong. That seems like a strange way to measure it. I trust that the team will capture the spirit of the goal, which is to be as productive as possible and use the tool intelligently. We weren't even tracking token spending internally until last week, because it wasn't a priority for me in terms of token spending on the product. Wait, before we get to that, they started last week, what motivated them and what conclusion did they reach? Well, basically what motivated us was asking ourselves: "Do we even know how much we're spending?" Or to say, " We should know how much we're spending." It was basically because people were using Fable and someone said, "I think I spent a couple of thousand dollars today." And we said, "Okay, maybe this is something we should at least be aware of." We literally did the same thing. Fable came out and Kieran, who directs Kora, was on track to spend about a million dollars on credits in a... in a year. In one year. And we said, " Okay, we need to think about this a little ." Yes. Yes. Yes. It might actually be worth it. And we also have to think about it, you know . Exactly. Yes. Yes. This leads us to things that are always beyond our control. It's one of those things where you think, "Oh yeah, we should probably at least know how much we're spending ." It sounds very obvious, but we're just so busy with so many other things. It's like now is the time. Regarding the product, I still believe it's in its early stages and that we have much to gain by discovering the most impactful native AI experiences Granola can create, and therefore we're not very aware of the costs involved in token spending. As I said before, we pre-generate, I don't know, millions of these summaries even though only 10% are opened, because we want to discover what the right user experience is. We believe that both costs will decrease over time and that we will be able to optimize them once we know what the best experiences are. So that has been our philosophy. Agent functions are really expensive. And as we create more and more, at some point that will break our numbers. But for now, that has been the priority. And how much do users use agentic workflows in Granola? I'm asking out of pure curiosity whether regular users learn to use advanced features like that. It's the word "agent" that's complicated, isn't it? I think... The answer is about half, right? On a weekly basis, around half of Granola's users use us agentically. Although I don't know if they would describe it that way, if that even makes sense. As they, you know, will do a consultation that is like a complex type of consultation about, uh, um, you know, let's say your coaching or improvement question, where it will analyze a series of meetings over time and then do several steps of analysis on that, right? That kind of thing takes, more or less, half a week. Yes, it's very interesting. Um, Chris, if people want to find you online to use Granola, where should they look? Um, I do n't know. Well, Granola's Twitter or X account is meet granola. Uh, mine is CJ Pedrical. That is, CJ, my last name. Um, and yes, I guess those are the best places. Incredible. I always love talking to you. I love what you're building. Thank you for coming. We need to do this more often. Yes, absolutely. Whether it's on the podcast or just the two of us chatting. I really enjoy these conversations. I think it's excellent. Oh, heavens, friends. They absolutely and positively need to press that like button and subscribe to AI and I. Why? Because this program is the epitome of genius. It's like finding a treasure chest in your backyard, but instead of gold, it's filled with pure, unfiltered knowledge bombs about ChatGPT. Each episode is a rollercoaster of emotions, ideas, and laughter that will leave you on the edge of your seat, wanting more. It's not just a show, it's a journey into the future with Dan Shipper as the captain of the spaceship. So, do yourselves a favor, hit like, hit subscribe, and buckle up for the ride of your life. And now, without further ado, let me just say, Dan, I am absolutely and desperately in love with you.