Granola's Chris Pedregal on Building a $1.5B AI Company

Transcript

You are the co-founder and CEO of Granola, one of the first new AI apps where people were like, holy shit, this actually works. Meeting notes are not the end-all, be-all value that everyone's running after. There's something much bigger. I think we are in the very, very early steps of a computing revolution. What has come thus far will pale in comparison to what will come soon. [SPEAKER_03] Startups are like knife fights, and I thought startups were just really hard when they weren't working. Turns out they're really hard even when they're working as well. Every is the only subscription you need to stay at the edge of AI. If you care about being on top of the latest models and using the latest tools, you have to subscribe to Every. We'll help you separate the signal from the noise. Go to every.to slash subscribe today. And now back to the episode. Chris, welcome to the show. [SPEAKER_02] Hey, Dan. Great to see you. Good to see you, too. It's been a while. So for people who don't know, you are the co-founder and CEO of Granola, one of my favorite AI apps. One of the apps that I think really kicked off the wave about two or three years ago. It was one of the first new AI apps where people were like, holy shit, this actually works and it's useful. And since then, you've gone on to build a team of about 55 people. You've raised at a $1.5 billion valuation. You're just killing it. And we had a really good conversation in December 2024, so almost two and a half years ago, about putting soul into your product and making products that are delightful. And I'm just super curious to hear what's on your mind, how things are going and to sort of share out both of our journeys over the last couple of years and think about the future together. [SPEAKER_02] Couldn't be more excited to chat. I've been following all the different things you've been doing, you know, from a distance. I'd love to hear the latest from the inside on how that's going. Just to react on one thing you said, you said we're killing it, right. And we're very lucky. Things are going well. What something I was unprepared for—so I did a previous startup and startups are like knife fights, right? They're really hard. I don't know, maybe life's easy for you, but for me, it's really hard. And I thought startups were just really hard when they weren't working. Turns out they're really hard when they're working as well. It's just a knife fight. When things are going well, we're not going well. And I was a bit unprepared for that. So I'm just, I had a professor in journalism school who was basically like, the last thing the world needs is another profile that puts someone up, you know, it's like, oh, this person's so great. And it's like, no, everything's hard today. Day in, day out, that's my mentality. So just wanted to share that. I feel you, man. I definitely feel the same way where I've been doing companies for a long time. And Every is the first one that's really growing and just really working in this way that feels like it's a real company. We have 30 people now. And when it is working, a good example is Claude tag dropped yesterday. We've been working on a Slack agent, Claude tag dropped yesterday. And so then everyone's looking at you like, what do we do? And I'm like, we're prepared for this. We've been thinking. We knew this was going to happen. And especially in AI, I feel like the ground shifts so quickly. And I assume for you, like one of the things you're talking to—and I'm actually really curious—is you were the first one to do really great AI meeting notes and meeting transcriptions. And then immediately everyone just put meeting notes into their product. We actually have a product called Monologue that has a meeting notes button, you know? [SPEAKER_02] Oh, cool. I didn't know that. So we're slightly competitive. [SPEAKER_02] Welcome to the fray. [SPEAKER_03] Yeah. I don't really think of it as being an exact one-to-one replacement. I actually have both on my computer, but still that's probably what you're referring to when you say knife fight. So tell me about that. What is that? How has that actually affected your business at all? [SPEAKER_03] That's actually not what I was referring to as a knife fight. I mean, that's part of it. You know, I think it's just—I guess what I was referring to is that by definition, a startup is you're either fighting for survival. You're always fighting for survival. And if things are going well, you're fighting to stay on this big wave and you're on the surfboard and you're trying desperately not to fall off that surfboard. And so you're always just beyond the edge of your abilities. And it's almost by definition. Therefore, you're always doing stuff you don't know how to do. It's like, yeah, actually that's been my experience. It's like I'm always just in the space where it's stuff I've never done before, or it's just more than we've ever bit off in the past. Yeah, the competition. Here's my view. And I feel like I've said this. Let me think about it. So I think this is going to sound like one of those bullshit answers around competition, right? Because there's always the interview where it's like, hey, Microsoft just copied your product. How do you feel about it? And the founder has to come up with some answer. The way I view it is that I think we are in the very, very early steps of a computing revolution. And what has come thus far will pale in comparison to what will come soon. So I think the, when I think about this, this is going to sound like one of those bullshit answers around competition, right? Because you, there's always the interview where it's like, "Hey, Microsoft just copied your product. How do you feel about it?" And the founder has to come up with some answer. The way I view it is like, I think we are in the very, very early steps of a computing revolution. And what has come thus far will pale in comparison to what will come soon. And I think that meeting notes are not the end all be all value that everyone's running after. There's something much bigger. And I think it's the interface we use for work and how we work and what does that look like in the AI native world? And so when I think about competition, what people are fighting for today doesn't matter. There's this incredible opportunity ahead. And I think we have a shot at it and a few other companies have a shot at it. But that's really what matters. So in the same way where people are like, "oh, Granola is doing really well." It's like, well, in my mind, it's easy come, easy go in a way, right? Like meeting notes are useful, but a lot of things are going to change in the future. And just because people use us today doesn't mean they're going to use us for that in the future if we're not the best at that next thing. So yeah, that's my zoomed out view. And the other thing to say is we were not the first meeting note taker, right? AI note takers have been around for ages. We were heavily inspired by a lot of things that came before. [SPEAKER_03] So I, you know, I can't be like, "oh, how dare you be inspired by what we did?" It's like, we're just in an ecosystem. It has affected the company a lot less than I thought it would. Like I think when Notion copied or whatever, let's say we're launching something. I think heavily inspired by Granola's opening. I did Zoom did recently. So it's like, in some ways, I didn't have to sit with the nightmare scenario of like, what would it be like the day that launches? It came and happened. And we're still here. We're still like, it hasn't changed anything from our growth rate or whatnot, but again, we're still a drop in the bucket compared to what we'd like to be in terms of how people use us and how many people use us. So I think it's just very early days is my view. [SPEAKER_00] I just gotta say, I love getting to talk to you because I feel like you're just so honest about what you're dealing with. It's the best. It's so fun. It's very different from a lot of people. And I think this is going to be a very fun conversation. What I want to go back to is, um, and I'm happy to share too. You said you're balancing on the surfboard and you're trying not to fall off. And normally in startups, you're on the surfboard and you're paddling and you're waiting for the wave. And then I think for both of us, for you more so than me, but for both of us, you're like, I'm on the big one now. Let's try not to fall off and just get pounded, you know? And so what are some of those things recently where you've felt like you've been at the edge of your ability and you're like, I gotta figure this out. This is maybe a good thing, but generally it's like, holy shit, this is very different. So a lot of it's my limitations or lack of experience as a founder. So like my last startup, Socratic, we were 12 people. So going from 12 to we're actually over somewhere between 60 and 70 now. And so there's that, which is very different and I've never done that before. So organizing humans is one thing that's challenging. And I wish I had a really succinct, beautiful answer like we have it all figured out, but it's, in an era where you're talking about product having soul and product feeling consistent and coherent and tasteful, how do you scale that? Like when you have more people working on that, how can you both get the upside of having lots of people working on these hard problems, but also having this consistent feeling? That's a really hard problem. And I think there are so many different interesting topics for us to dive into, but one is the traditional roles of PM and design and engineering and how you group those people together and what are their responsibilities. Like it feels like what has worked in the past may not make sense exactly one-to-one in the world of the future, but I don't actually know how to define roles and split work. [SPEAKER_02] You know, there's something really valuable if you're like, "oh, you're the designer, I'm the engineer," or vice versa, of like, okay, now we know where we collaborate, where the interface line is. But do you guys have a philosophy on that at Rewind? I don't know. [SPEAKER_03] and how you group those people together and what are their responsibilities. [SPEAKER_03] It doesn't feel like what has worked in the past may not make sense exactly one-to-one in the world of the future, but I don't actually know how to define roles and split work. There's something really valuable if you're like, oh, you're the designer, I'm the engineer or vice versa of like, okay, now we know where we collaborate, where the interface line is. [SPEAKER_03] But do you guys have a philosophy on that? [SPEAKER_03] We've done different things and it depends on the situation and the product. My one mental model that I have that seems to work, especially for early products is there are two roles that matter. One is called the pirate and one's called the architect. The pirate's job is just build as fast as possible to find something valuable. It can be vibes coded. You don't have to really think about the architecture. And the architect's job is to pair with the pirate and think about as the pirate finds something that's valuable, how do we make this into a system that is sustainable, that we understand, that can scale. What's interesting is I think you need one pirate per product, but you can have one architect work on multiple products. You can have them bounce around because the tools now are so good that someone who's a really good programmer, really good architect can just drop into a code base and be like, I'm going to learn this code base in an hour because I just have Claude or Codex or whatever, map it for me. And then I'll identify the structural pillars, the invariants that need to be true in this product for it to work well. And then I'll just send off Codex to do a 24 hour rewrite and then I'll go do something else. That's really interesting. So that's one divide. And in particular, the pirate is this mix of technical, product, design, all of those all together. And the architect is really mostly focused on the technical side of things. [SPEAKER_03] So you don't have standalone designers then, right? We do have standalone designers. Once it gets to be a real product that we're going to support, then we have a standalone design. We have a design team that parachutes into each product and helps make it better. But on the tech side, for example, we have this Slack agent we've been building called Plus One. That's just a bunch of engineers that are all working and are to some degree full stack thinkers, but it's very engineering focused. So there's no one answer. I haven't quite figured it out yet. I do think the pirate architect configuration for new things is really helpful. What do you guys do? [SPEAKER_03] We have something similar, but it's not actually on the role. For any kind of new feature, we have this idea of stages. The first stage is shaping. We're influenced by Shape Up. A lot more dated from the features that they use as examples, the features that they're talking about building. But some of the ideas I think are really sound. So we have this idea of a shaping phase where what you want there is you want to explore as many potential solutions as possible. So you start with a job to be done. Here's a user need, here's the job you would like the user to hire us to do. Okay, this is the job. What are possible shapes of that solution? And you explore those shapes as quickly as possible. And then you look at those and you have to be very honest with yourself and say, if we spent time on this, do we think we could actually make something people would hire us to do? And then we have a next phase, which is validate. Okay, we think we can prove it. For a small number of people, just prove that you can be useful and that they choose to use you. And then if you can prove that, then it's okay, let's actually make this good and reliable and scalable. It still doesn't answer the question of who are the people who work on it. But you have 60, 70 people. So you've had to answer that at least provisionally. What is the structure that you've come to provisionally? people, just prove that you can be useful and that they choose to use you. And then if you can prove that, then it's okay, let's actually make this good and reliable and scalable and all that. It still doesn't answer the question of what are the roles of the people who work on it. But so that's just one of those open questions. I mean, you have 60, 70 people. So you have had to answer that at least provisionally. So what is the structure that you've come to provisionally? We're still messing around with it. We still have titles and I don't know if we should have them. We have, you know, you're a designer, you're a PM, you're an engineer. Right. And I'm always flirting with the idea of killing those. How many PMs do you have? Four, three, depends if you count me. Yeah. I wouldn't count you. Yeah. I've always been flirting with the idea of killing it because what you really want is on this project right now, someone needs to do certain types of things. Someone needs to own the aesthetic or the user experience and someone needs to own the building and that could be the same person, or those could be two different people. Right. And someone needs to own what are we trying to do here? And what's the strategy? And what are the next few things that we need to hit in order to hit that? [SPEAKER_03] But then it's a lot of communication overhead if you don't have roles, right? It's okay, well, what exactly are you going to do versus what am I going to do? Maybe it'll all be agents one day, who knows? We'll keep experimenting. Interesting. Well, one of the things that you said when we were just about to start recording is you spend most of your time in Granola. And so one of the things you're curious about for me is if I'm playing around and experimenting, what am I finding? So I want to talk about that. I think there's a lot of meat there. First of all, tell me about that. The fact that I spend most of my time in Granola. I think that makes perfect sense, but also as a CEO, as a strategic way of being, tell me about that decision. So I mentioned before 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. That's what we're all chasing right now in Silicon Valley. And to that end, I think there's a lot that you can think about abstractly, but then you have to be playing with to get a feel for. And it's hard for me to have the brain space of playing with every new thing that comes up. Right. And in Granola, we have a lot of context and a lot of internal tooling so that I can play around with different ideas, but they're in my little universe, as opposed to setting up very complicated workflows in Claude, for example. I play around with it to get a feel, but those aren't load bearing for me because I'm trying to see what makes sense or doesn't make sense to do inside of Granola as we paint that future picture. It seems like you are at the forefront of experimenting, trying new things, building different workflows for yourself. So maybe just start off by being what's the current state of Dan's tooling stack. And then we can go from there. I spend all my time in Codecs. Okay. Almost. How long, and how long has that been? Like two, three months. Okay. Um, and I do use the Claude desktop app sometimes. When Fable was a thing, I tracked all my usage. And when Fable was a thing, you can see me go on Claude usage. And then when it left, it went down. So I assume when it's back, because I think Fable is just a different beast. And I test all the new stuff and I have access to stuff before it comes out and Fable is just different. But I think of my overall view is that work is bifurcating into two surfaces. One is async delegation work that happens in Slack. That's collaborative multiplayer, sometimes proactive. And that happens with Slack bots. We have one called Plus One, there's one called Victor, there's the Claude's tag. And that's okay. Every morning it posts in a channel and says, hey, here's all the bugs that got solved. Here's all the bugs got reported. Here's all the PRs we pushed. And then you can add it and say, can you kick off a PR for XYZ bug and it just does it. Or can you read all the stuff we've said about what we want the product to be and then propose some names. And then the team can go back and forth with it in the same channel to talk through names. So you can hand off stuff with it like it's a coworker. And importantly, because most AI right now is single player, you can do it in public. And I think that's really interesting. However, for serious work, you can't. You're always going to get more out of it if you have better collaboration between you and the agent and Slack is not good for that. And so the other surface is something like Codex or a Cloud desktop app where you and the agent are sitting in the same place on the same app together. And in particular in Codex, for me, it's I use almost all of my software in the in-app browser of Codex. So I'm bringing Codex into my email or into whatever it is in the same way that, what do you mean by that? Can you describe that? How do you do that? I'll explain. So when you're building something in Codex or Cloud Code and it opens it in app browser and it lets you see the localhost version of the thing and you're iterating on it. the agent are sitting in the same place on the same app together. And in particular in codex, for me, it's like, I use almost all of my software in the in-app browser of codex. So I'm bringing codex into my email or into, whatever it is in the same way that, what do you mean by that? Can you describe that? How do you do that? I'll explain. So when you're building something in codex or cloud code and it opens it in app browser and it lets you see the localhost version of the thing and you're iterating on it. All of the patterns, a good mental model for how AI works for me is all the patterns [SPEAKER_02] that started with developers or builders eventually make their way into all of knowledge work because we, what we found is that building a good enough agent to build any kind of software. Once it can build any kind of software, it's actually really good for doing any kind of knowledge work that you want. And that's why cloud code went to cloud co-work. That's why codex is now all of knowledge work, all that kind of stuff. So one of those patterns is when you're building something like an app, what you really want is the agent to be in the loop with you. So as it builds something, it opens an in-app browser, you can see it and you can go back and forth. You can annotate it, whatever. And you and the agent are seeing it together. That pattern also works for any kind of software. So any kind of website you might visit. So really simple example. Last night I moved departments recently and I needed to change my internet and I just told codex, go figure that out. And it knows the address of my old one and my new one, which is actually the same building. I'm just moving floors. It just opened up the Verizon website in app browser. And it logged in. I gave it the password. It logged in. And then it opened up a chat with a customer service agent who was also probably using AI. And it just chatted with them until it switched my internet. And all these little things come up where it's, okay, when do you want to move in and out? And codex knows because I've been talking to it about when I moved and when I wanted to switch. And then it's, here's, here's your old plan doesn't work. Here's the new plan. And codex knows to be, I don't want any hidden fees. It knows how to do the math on, is this a good deal or not? And to be able to research it and then to push them to give me the thing that it thinks I should get. And I don't have to do any of that. I'm just sitting there. And is that something that you somehow communicated to codex or is that just out of the box? Obviously any human would want this when talking to an internet provider. It's both. It's easy because it will know pretty well when it can make assumptions and when it shouldn't. And so I can be in the loop on it and I also can just go to another thread and be doing something else. So I'm flipping back and forth with it. I think that's something, but there's a more general thing there where I use, this is how I do my email. It is in the loop with me in Quora, which is our email app. And I have this open source thing I experiment, I built called tend, but basically my emails are now cards that I read in codex in the in-app browser. And then each card, it says, here's what the email said. Here's what I think the draft should be. Do you want to send it? And I just talk to it. I see. So this is basically you've vibe coded your own email client, right? Is that I've voted an experimental email client that does this. And then we will have a version of Quora, which is our full email client that just has this out of the box. But you can think of the apps that are structured this way as being, I've been calling them codex native apps, but they're basically apps that are responsible for saving the state and rendering the UI and you bring your agent to it. And I think that is a much more powerful paradigm because think about all the work that you have to do for granola to make an agent that is good. And it's really hard. And you're also competing with the clods and the codexes of the world who are also building the same kind of agent with the same kind of functionality. And to some degree, I also think that, [SPEAKER_02] in some cases that's very worthwhile. Cause I do think two agents is 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. [SPEAKER_02] You already know how AI is changing, how everyday work gets done, how much ground you can cover and how fast a team can scale to stay ahead. You need tools that give you a competitive advantage built for this new era. Adio is the CRM for the agent native world. It meets you where you work, compounds every customer signal into context, and then acts on it across your pipeline to let you move at unmatched speed and scale with agents and automations for every job. Adio orchestrates your work around the clock. We use it internally at every, and we love it. It's built to handle the scale of your workloads. It's extensible with an API and MCP access, and is built with infrastructure to keep up with your most ambitious agents. It's loved by high growth startups like granola modal whisper flow and every. Adio runs the work behind every win. That's adio. The agentic CRM. Go to adio.com slash every and get 15% off your first year. That's adio.com slash every. And now back to the episode. What do you think, yeah, you keep saying that, and I'm really excited about that idea. I wonder how does that work in practice? Like if, forget granola, but you know, let's say you, I don't know, can you do this with Quora right now? Or how, how do you build it? How could we build an app that would allow you to bring your own agent? That's not, you know, MCP. Cause it feels a little bit different, right? Cause it's like, you still want to have the UI [SPEAKER_02] slash every and get 15% off your first year. That's adio.com slash every. And now back to the episode. What do you think? Yeah, you keep saying that, and I'm really excited about that idea. I wonder how that works in practice. If, forget granola, but let's say you, I don't know, can you do this with Quora right now? Or how do you build it? How can we build an app that would allow you to bring your own agent? That's not MCP. Because it feels a little bit different, right? Because you still want to have the UI that's the difference. It's like you and the agent are both looking at the same UI and manipulating the same thing. MCP is part of it. But yes, I think MCP is historically thinking about it as the agent is going to interact with the app and I'm not going to interact with the app. And what I'm thinking is actually you want your agent and your user to be interacting with the app at the same time and be able to trade off. And so the way that you do that is one, you give the agent access to an MCP or a CLI. And then you give the user access to a web interface and the user is using the web interface inside of an app browser of a codex or of a cloud code. And then the agent can decide, do I want to help the user or collaborate with the user via using the browser use or via using the CLI, which I think CLI is somewhat better, but the trick is the CLI has to then modify the state of the UI. Right. Exactly. That's the thing that needs to be. So it's almost like if you had hypothetically an MCP, right, that actually had a stateful MCP could modify the state, like real-time state of a UI that was rendered for a user. And ideally there was at least a one-to-one mapping of anything you can do in the UI could also be done through the MCP. So you have an agent and a human interface. Because computer use or the web browser use feels like it's unnecessarily slow, right. It's a hack. Okay. That's really interesting. Yeah, there's something about the presence of the agent. This is a fascinating topic. I haven't thought about it very much, but the embodiment of the agent is also maybe interesting, you know. When you're in Figma, you can see other people's locations on the canvas. And there's something there that you would maybe lose if there was just an MCP and the human, maybe not, I don't know how you feel. Is the agent just the computer and that's all the same, or does it feel like it's an entity that you're both looking at the same thing together? [SPEAKER_02] That's it. It's in the same way that with Google Docs, like we have this markdown editor called proof that we built. And in that one, you can see codex has entered the document and you can see where it is. Oh, that's cool. How do you do that? How does codex enter the document? [SPEAKER_02] It's the same kind of CLI MCP type situation, but it has a command like, okay, set presence, set location in the document, that kind of thing. And agents are very good at knowing how to do that. But there's so many interesting UI challenges to figure out because an agent can do a thousand different actions at once. And so how do you show that to a user? That's actually not where my brain went. Because you're right. If you want to see what the agent's doing, that's one problem. I was just thinking in an email, it'd be nice for it to know where your mouse is. It'd be nice to be able to like, just be like, oh, this part of the email is not great. And just have that be either you highlight the text or whatnot. And that's not really possible today, unless you explicitly, how would you have to do that? It would have to be looking at pixels on your screen, right? There's no native way to do that unless you build it into a UI and you're passing that information to the agent, right? [SPEAKER_02] More or less. I think the way that I do it is each piece of information that I want to take care of is represented in a card. And then I can talk to the card. I can say, yeah, it doesn't necessarily know where my mouse is, but it knows that I'm talking to this part of the UI. And it just knows because you say that when you're talking to it or because that is the main thing that's foregrounded in the app? [SPEAKER_02] Whatever I'm looking at is currently focused. And so I know that it's focused. And then when I'm talking to it, it just knows to put that context next to that thing that I'm looking at. Okay. That makes sense. And you're actually speaking, right? This is like you're using monologue or whisper. [SPEAKER_02] Yeah. Using monologue or something like that. Right. Yeah. That's sort of my view of work and how things are going. And we've been talking about, okay, there's this word there, the prize is there's a new way of working. How does that fit into or differ from how you've been thinking about it and your strategy for granola? I don't know. I took this class once and they were talking about the difference between complex and complicated problems. Have you heard this? [SPEAKER_02] Yeah. Yeah. And it's like complicated, it doesn't mean it's going to be super hard, but it's kind of knowable, you know. Versus complex problems, it's unknowable. You have to probe the system and see how it reacts and go from there. And so I think we're very much in a complex problem space here. So I don't have an overarching theory [SPEAKER_02] I don't know. I took this class once and they were talking about the difference between complex and complicated problems. Have you heard this? Yeah. Yeah. And it's like, complicated, it doesn't mean it's gonna be super hard, but it's knowable, right? And versus complex problems, it's unknowable. You have to probe the system and see how it reacts and go from there. And so I think we're very much in a complex problem space here. So I don't have an overarching theory of where this is all going. I think I could make one up that would sound plausible or as plausible as the next person's. But I'm more in the mode of, what are things that, what are insights or nuggets? And I'm like, okay. I've now learned this is a thing. And now I believe to be true and I'm gonna carry that with me. Um, and so I have a few of those. Like one is, it seems like one fundamental design challenge in this agentic world is the time traveling problem. Basically agents take time to do things. And therefore when you're talking about Slack as an interface for this, which is the async delegation problem, I think you said before, which is basically the moment in which you kick off a task and the moment when you're reviewing the task are disjoint. And then you need to get all that context into your head. And I think that'll be one of the things you'll see a lot of. The interfaces that evolve to be highly optimized for that. And I haven't seen anything that's great to be honest. Like, I like the conductor. It's like, oh, I've got all these different chat threads and I'm jumping between them when it's kind of ready. It feels like there'll be evolutions beyond that that are coming. Um, another one that's been interesting is another way to get around this, it takes a while for an agent to do thing problem is, pre-process a bunch of stuff. Like if, so like granola, one thing that we figured out is if I ask granola to do something and I have to wait 20 seconds, basically humans will rarely wait for 20 seconds. If they're in back to back meetings, chaotic, crazy workday, which is the user that we're thinking about. But if granola kind of thinks about something you might want and then pre-generates it, and then at some point might be like, oh, here in case you want this, it's already here. And all you have to do is click on it. That's completely different. Um, and so we have some examples there. Like we launched this thing recently where granola will try to generate a brief for you before a meeting where it's basically, here's this person you're meeting with. Here's the context of who the person is, if it's a first meeting or what you guys talked about last time, if it's another meeting and this one, you essentially have to pre-generate it. Cause it's useful when you're running two minutes late to a meeting and you're like, wait, who the heck is this person I'm talking to again? And that's the critical moment. So you really only have a 15 second window where it needs to be there or it's kind of useless. Um, so we actually pre-generate millions of these. Um, we pre-generate a silly amount of these for a small percentage of them actually being opened. In the belief that when you do open it though, you really appreciate it. Cause it's exactly what you need in the moment of need. Um, it's an interesting trade off there, especially from a cost perspective. Cause we're talking hours and I don't know, hundreds of thousands of hours of agents reasoning about things that may or may not ever get to see the light of day. And how are you measuring that? Like whether that's worth it or not? [SPEAKER_02] It's an open question. Um, I don't know how to measure it just yet. What I'm trying to figure out is we don't have a good metric between that. Like if something's not used at all, it's obviously not good, right. But then there's if something is used a little bit or a decent amount, but it's really load bearing when it's used and that's still very valuable. I'm trying to figure out how to measure what that is. Right. Like I was at a founders conference the other day and four founders came up to me and talked about this pre-meeting brief feature, which surprised me because it's not used as much as like proportionally. That's not what I would have expected. Um, so yeah, we have this analogy, metaphor. I always forget which one of those is inside of granola of how we want the granola product to feel. And it's like a handrail. So if you imagine stairs, all stairs have handrails, right. And it's basically like, you never notice a handrail, it's invisible, but that moment you trip, your hand shoots out and it needs to be right there and it needs to be load bearing and it makes stairs way safer. Uh, and that's how we think about granola, right. We kind of want to get out of the way until you really need us. Um, but yeah, we probably need better metrics or frameworks to measure. One thing we thought is if we just take it away, if we take it away from a number of users, how much do they shout or what's the impact of us doing that? But even that has issues. It's not the best way. Or maybe seeing if they will click to generate, click to generate, as opposed to here it is. And it's already generated. But would you take the proactive action to do it? [SPEAKER_02] Of doing it and then it's there. Yeah. Yeah. But then once, and then it's like, [SPEAKER_02] We probably need better metrics or frameworks to measure. One thing we thought is if we just take it away from a number of users, how much do they shout or what's the impact of us doing that? But even that has issues. Or maybe seeing if they will click to generate as opposed to having it already generated. Would you take the proactive action to do it? And then it's there. But then once they do, are we always going to make them click? I don't know. It's a tricky one. That is tricky. Well, then how do you think about what is Granola's role versus Codex and the co-works of the world? And what do you see as being places where you want to integrate and make yourself available to what they do versus places where you're like, I want to own this. This is something that we can uniquely do well. [SPEAKER_03] Yeah. So my view here is that it's a new era of computing where for the first time computers can make sense of our context and you can do amazing things with that. And to that end, having the right context is really critical to getting value out of AI. So my belief is that the context you have in Granola, we should make that as available as possible, however you want to use it. So if you want to use it in Codex, if you want to use it in your personal agent, if you want to use it, whatever. If it can make your life better to use Granola context, you should, and we should make that really easy. And our API or MCP is going to get a lot better over the next couple of months because that's a first class goal of ours. I think there are a number of jobs to be done, pain points, use cases that we should just be five X better than anybody else in the world at. And those obvious ones are all related to meetings, right? It's just one of those things where I think that the models are going to keep getting better, but if Granola just cares about a few things way more than anybody else and we optimize the hell out of those things, they'll just be a better experience, especially if they're tied to a UI that you have to use in vivo, like during a meeting, for example. And so that's our current strategy. It's basically be best in the world at anything that's meeting adjacent and then be the best way to capture context to power any agents you have. And I can give you an example. I was talking to a user and they were doing something really clever. She worked in sales and they basically used Claude to generate a microsite before they would talk to a potential client. And the microsite was really impressive. They had a template and then Claude would style that template to look like the customer's website. And then they would connect the Granola MCP and just pull all the context from Granola and fill out all the data and the fields and the widgets based on that data. And that's just the kind of thing that we would never try to be best in the world at and wouldn't make sense to. But she would also be writing a lot of emails in Granola right after meetings, cause follow-up emails and Granola made a lot of sense for her. And that's the kind of thing where it's maybe we don't want to write every email. We don't want to be your email inbox, but there might be a type of email that you want to send right after a meeting that is extremely good on certain dimensions that we could be the best in the world at. And it makes sense to do both. I don't think it's one or the other. I was undecided about this two years ago when we started Granola. Now I have strong conviction, but it took me a while to figure that out. That's interesting. Yeah. I think from a user perspective, and I may not be your core user, and that's actually really interesting to me to learn that. Cause one of my convictions is that what builders do now, people who want to figure out these general purpose tools and build these workflows, regular people are going to do in a few years, once they're more built in it, once it's built into the handrails of these products. And so what I do is I just play around with stuff and try to figure out, oh, this is what I use Codex and Slack agents and whatever for. And eventually that will make its way into maybe stuff that we build, but stuff that the labs build or stuff that other people build. And we get to see it first. Can I ask a question about that? Cause I think, is the theory that the stuff that you are trying to automate with AI or the interactions you're trying to build, do you think that other people will also be building their own version of those automations, or do you think those will be productized? Yeah. Okay. We have the same view. So yeah, I think you're the guinea pigs, right? So basically, yeah. And we have tons of guinea pigs using Granola, right? So my view is basically we should just look at what are the most common and cutting edge ways in which people are using our API and MCP to do stuff and then figure out which of those do we think we could be the best in the world at and a lot of users would benefit from, and then build a really beautiful, seamless product experience that might've taken like I was, will be productized? Yeah. Okay. We have, I have the same view. So yeah, I think you're the guinea pigs, right? So yeah. And we have tons of guinea pigs using granola, right? So it's like, my view is basically we should just look at what are the most common and cutting edge ways in which people are using our API and MCP to do crazy stuff and then figure out which of those do we think we could be the best in the world at. And a lot of users would benefit from, and then build like a really beautiful, seamless product experience that might've taken, I ran into the founder of one of the founders of hugging face the other day at a conference. And he was like, man, I had built this super convoluted, complicated pre-meeting brief workflow in cloud code. And I'd been working on it for months and I just turned it off because yours was better. You know, and that, and that was like, that's exactly what I want. And I can't do this for everything, but that's exactly what I want because we're just going to care more than any individual should ever care about any one workflow. I think that's exactly right. Okay. So we're definitely aligned there. My current feeling is in general when I see granola, like the UI come up, 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 that I want to access it is going to be it pushing something into codex, which is my work surface or codex pulling something out of it. And I think this focus on meetings is so right. And it's actually such a hard and deep problem to just get that context right? So for example, I mean, you know this better than I, but I'm just thinking about when you do a transcript and I say the name Chris, which Chris are we talking about? Right. Um, and so I think of the job of software companies in an AI world, AI is this really super flexible thing, but it's only flexible if it's given the right structure and the right context within which to be flexible. So if we're using the human body as an analogy, AI is like the ligaments and the muscles, and then the software has to be the bones. Um, and the bones sort of set, give it form and structure, but then the AI can kind of work around that to do anything. And there's so much, even for example, in a meeting transcript, I might say, that's a good idea, but the way I say that means a lot about what I actually think that is not captured in just a transcript. And I want granola to be like I have this automation that runs that turns all the slacks and all the meetings that I was not in into cards that I just go through and I can see things that happened in the company, but the transcripts are often wrong and they capture none of the nuance of how and why things were said. And I think that 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. Um, and maybe for a more normie user who doesn't want to be in codex all the time. Although I do think that that's going to be more and more the case, you still want to have the UI, but there's all this background context processing that I would look to you guys to do that. I don't really want to do. [SPEAKER_03] Yeah. Yeah. Yeah. No, that makes total sense. I think the transcript is one way to capture the context from a meeting, right? It is the simplest way. And there's, LMs are weirdly good at making sense of garbled transcripts and doing something useful with that. Um, I think, but what's the actual job to be done here? It's actually like, what are the insights or what are the decisions or what are the actions I need to take on top of this context? And there's this layer of intelligence or interpretation, which is like the disambiguation, like which Sam did I mean, is a great example. Um, we have this, so we have this, I'll give you there are challenges. It's such an interesting space. So here's a challenge we have, right. Um, if 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 don't use it yet. And I'll explain why generate a pretty high fidelity picture of like who you are, what you're working on, what you're trying to achieve, what are your challenges, who you're working with on different things on. And let's just for argument sake, let's say this a two page summary of like who Dan is today, right? The state of Dan today and it changes every day and we can generate better notes if we pass that context in this part of our note generation pipeline. Um, but now those notes might include information that didn't come from the meeting. Right. So like when you said it's like, oh, that's interesting. Or what was your example? It's like, oh, I like that idea. And we might be like, Dan doesn't actually like that idea. He thinks that's a terrible idea. Cause we know he hates that general class of idea. Cause he said that five other times and five other meetings. And so then there's this interesting question of like, who's the audience, right? And today, a lot of people still, they'll use the notes for themselves, but they'll also, there's this mixed use with also share it with other people. Right. Whereas the perfect notes for you are actually probably a little bit different or the perfect notes are just one. Um, it's just one way to represent that information. You know, there's other ways. And it's like, what level of intelligence or interpretation would you want granola to do? Yeah. But yeah, I totally hear you. This is why I think it's infancy days for us. Yeah. Or honestly, you seemed really stressed in that meeting. Do you want to talk about it? Would be really, really interesting. [SPEAKER_03] They'll also share it with other people. Right. Whereas the perfect notes for you are actually probably a little bit different. The perfect notes are just one way to represent that information. There's other ways. And what level of intelligence or interpretation would you want Granola to do? Yeah. But I totally hear you. This is why I think it's in its infancy days for us. Or honestly, if you seemed really stressed in that meeting, do you want to talk about it? That would be really interesting. Maybe people would be freaked out by that, but one of the things I use Granola for a lot is management stuff, like how do I do there? Or someone on my team had a difficult conversation with someone on their team and they're talking to me about it. And I'm like, let's talk to Claude about the meeting transcripts so we can decide what to do. All that kind of stuff. To do it well, I need not just the transcript, but there was a long pause after XYZ said this thing. No one said anything for three minutes. You don't see that in the transcript. Yeah. Stuff like that is just so much richness there to be had that I want Granola to do for me. Yeah. That makes total sense. I'm also curious, what are all the main ways? He was like, I don't want to see the Granola UI. I want to pull that into Codex or whatnot. And I also wonder, what are the main workflows or reasons why people are pulling transcripts or meeting notes into their agents? And which of those, if you were to optimize around, you would do a better job at? And which of those are the long tail, where you give people power and they'll do a better job? [SPEAKER_03] Yeah. What is on your mind for the next six to 12 months as these models evolve? You saw Fable come out. Does that affect your roadmap? Does that affect how you're hiring or how you're building? The order of operations, the questions that go through my mind first is, what does this change about how we build internally and how we structure our teams? That's the first question. I think our roadmap is something where you can have one plan in the abstract and then you actually play with something and you should adjust it. I unfortunately didn't play with Fable enough before it got yanked. But the roadmap is more baked into it a little bit more. Models will get better. Here's the general strategic direction. [SPEAKER_03] And that's more like our strategy is more dependent on what people use us for and what are the jobs to be done or use cases around that we can tackle. Model intelligence doesn't affect that directly too much, if that makes sense. Whereas model capabilities do affect how many people we staff on a pod, how we define goals there. Should we be approaching things completely differently? Yeah, that's on my mind for sure. The other thing is, I think maybe this touches on the stuff you're using Codex for. I think there's one or multiple canonical UIs that haven't been invented yet. Right now Granola, you have meeting notes. You can use meeting notes or transcripts or context for lots of things. Usually when you're trying to make use of that context, it's not per meeting. It's usually you have a set of contexts. In our case, all the meetings you had today or all the meetings you had this week, and maybe it's all the meetings and all the Slack messages and all the emails, but let's just keep it to meetings for a second. At that level of altitude, what is the right UI and interaction design to manipulate or work with that context? I don't think anyone has figured that out. Maybe you have, maybe you're cooking on something Dan, or maybe you'll figure it out. But when I look around, I've seen very little actually. Coming up with new UI paradigms is very hard, and it's very rare for new ones to stick around. I think they're more discovered than invented, if that makes sense. But there's a very clear gap I see there. We have a chat UI and chat threads are super valuable, actually surprisingly versatile and powerful when you're doing one thing. But when you're actually trying to do multiple things across varied contexts, I don't think we have the right metaphor there. So that's something that's very much on my mind. When you talk about the normie user, I think you're going to need a simple metaphor that the normie user can just understand and interface with. It's not going to be the kind of hoops you currently jump through with Codex. [SPEAKER_03] Yeah. How do you think about token spend both on your team and in the product? [SPEAKER_03] Okay, I'll do team first. I think folks on the team should be using AI to augment their abilities as much as possible. I think it's silly to say if you aren't spending this many tokens, you're doing it wrong. That's a weird way to do it. I kind of trust the team to take the spirit of the goal, which is be the most productive you can be, and be thoughtful about how you use it. We didn't even track token spend until last week internally, just because it wasn't a priority for me. In terms of token spend in the product. Wait, wait, wait. Before we get there, so you started last week. What spurred it and what did you come to? [SPEAKER_03] Fable. What spurred it was basically, do we even know how much we're spending? We should probably know how much we're spending. There was someone using Fable and someone's like, I think I spent a couple. [SPEAKER_03] Just because it wasn't a priority for me in terms of token spend in the product. [SPEAKER_03] Wait, wait, wait, wait, before we get there, did you start last week? So what did you come to? Fable. Well, what spurred it was, do we even know how much we're spending? We should probably know how much we're spending. And there was, basically because folks are using Fable and someone's like, I think I spent a couple thousand dollars today. And we're like, okay, maybe this is something we should at least be aware of. We did literally the same thing when Fable came out and Kieran, who runs Cora, he was on track to spend like a million dollars in credits in a year. And we were like, okay, we need to figure this out. Maybe we need to think about this a little bit. Yeah. It actually could be worth it. And also we need to think about it. Exactly. Yeah. This goes back to things outside of our ability. It's just one of those, like, we should probably at least know how much we're spending. That sounds like a really obvious thing, but we're just so busy with so many other things. It's like, now's the time. [SPEAKER_03] In product, I think I'm still a believer that it's early days and we have so much to gain by figuring out what are the killer AI native experiences that Granola can build. And therefore, we're not very cost conscious on the token spend. Like I said before, we pre-generate millions of these briefs, even if only 10% of them get opened because we want to figure out what's the right experience for the user. Our belief is both costs will go down over time and we can optimize costs once we know what the best experiences are. That's been our philosophy. Agentic features are really expensive. And as we build more and more of them at some point, they'll break the math for us. But for now that's been the priority. [SPEAKER_03] How much are people using true agentic workflows in Granola? I'm really curious about normie users learning how to use power features like those. [SPEAKER_03] The word agentic is tough, right? I think roughly half is the answer, right? Every week about half the Granola users use us in an agentic way. But I don't know if they would describe it that way. They'll ask a query that is a complex query around, let's say your coaching or improvement question work that will look at a series of meetings over time and then do several steps of analysis over that. That kind of thing is roughly half a week. Really interesting. Chris, if people are looking to find you online to use Granola, where should they find you? Granola's Twitter handle or X handle is meetgranola. Mine is CJ Pedregal. So CJ, my last name. Yeah, I guess those are the best places. Amazing. I always love talking to you. Love what you're building. Thanks for coming on. We got to do this more often. Yeah, absolutely. Whether it's on the pod or just us chatting. I really enjoyed these conversations. Sounds great. Oh my gosh, folks, you absolutely positively have to smash that like button and subscribe to AI and I. Why? Because this show is the epitome of awesomeness. It's finding a treasure chest in your backyard, but instead of gold, it's filled with pure unadulterated knowledge bombs about ChatGPT. Every episode is a roller coaster of emotions, insights, and laughter that will leave you on the edge of your seat, craving 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 yourself a favor, hit like, smash subscribe, and strap in for the ride of your life. And now without any further ado, let me just say, Dan, I'm absolutely hopelessly in love with you. So it's like, in some ways it's like, I didn't have to sit with the like nightmare submit scenario of like, what would it be like the day that launches? It's like, that kind of came and came and happened. And we're, we're still here. Yeah. We're still like, it hasn't changed anything from our growth rate or whatnot, but again, we're still a drop in the bucket compared to what we'd like to be in terms of, uh, how people use us and how many people use us. So I think it's just very early days is, is, is my view. That makes sense. I, I just gotta say, I love getting to talk to you because I feel like you're just so. Honest about what you're dealing with. It's, it's the best. It's so fun. Um, it's so, it's very different. It's very different from a lot of, a lot of people. And I think this is going to be a very fun conversation. What, one of the, but what, what I want to go back to is, um, and I'm happy to share too, what, what I want to go back to is you said, um, you're balancing on the surfboard and you're trying not to fall off. And. You know, normally in startups, you're like, you're on the surfboard and you're just like paddling and you're like waiting for the wave. And then I think for both of us, for you more so than me, but for both of us, you're like, I'm on the big one now. Like, let's try not to get, let's try not to fall off and just get pounded, you know? Um, and so what, what was, what are some of those things recently where you're, you've felt like you've been at the edge of your ability and you're like, I gotta figure this. I gotta figure this out. This is, this is, it's a, maybe it's a good thing, but generally it's like, holy shit, this is very different. So a lot of it's kind of, um, uh, my limitations or lack of experience as a founder. So like my last startup, Socratic, we were 12 people. So just going from like 12 to we're, we're actually over, we're somewhere between, I don't know, 60 and 70 now. Um, and so, you know, there's, that's very different and I've never done that before. Right. So like organizing humans, that's one, um, something that's, that's challenging. And I, I, uh, I wish I had, I wish I had like a really succinct, beautiful answer. Like we have it all figured out, but it's, um, in an era where you like, you're talking about product having soul and, um, product feeling consistent and coherent and, uh, tasteful. And, um, how do you scale that? Like when you have more people working on that, how do you, how, how do you, how can you both get, uh, the upside of having lots of people working on these hard problems, but also having this consistent feeling that's a really hard problem. Um, and I think, uh, I actually, I, well, there's so many different, interesting topics for us to, to, to dive into, but one is like the, the traditional roles of PM and design and engineering and how you group those people together and what are their responsibilities. Like I, it doesn't, it feels like what has worked in the past may not make sense exactly one-to-one in the world of the future, but I don't actually know how to, how to define roles and split work. You know, there's something really valuable if you're like, oh, you're, you're the designer, I'm the engineer or vice versa of like, okay, now we know where we collaborate, like where the interface line is. But do you, do you have a, do you guys have a philosophy on that at every year? I don't know. Like we've done different things and it sort of depends on the situation and the product. My one mental model that I have that seems to work, especially for early products is there are two roles that matter. One is called the pirate and one's called the architect. Um, and the pirates job is just build as fast as possible to find something valuable. And it can be vibe coded. You don't have to really think about the architecture, all that kind of stuff. And the architect's job is to pair with the pirate and think about as the pirate finds something that's valuable, how do we make this into a system that is sustainable, that we understand that can scale. And what's interesting is I think you need one pirate per product, but you can have one architect multi work on multiple products. Um, you can have them bounce around because the, the tools now are so good that someone who's a really good programmer, really good architect can just drop into a code base and be like, I'm going to learn this code base in, in an hour. Cause I just have cloud or codex or whatever, map it for me. And then I'll identify the, the structural pillars that the invariants that need to be true in this product for it to work well. And then I'll just like send off codex to do like a 24 hour rewrite and then I'll go do something else. And I think that that's really interesting. So that's, that's one divide. And, and in particular, the, the pirate is this, it's this mix of technical product design, like all, all of those all together. And the architect is like really mostly focused on the technical side of things. And then, but. So you don't have standalone designers then, right? You only have. We do, we do have standalone designers. Oh, you do. Like once, once it gets to be like a real product that we're going to support, then yeah, we have like a standalone design. We have a design team that, that parachutes into each product and helps make it better. But then on the tech side, like, for example, we have this, this Slack agent we've been building called plus one. And like, that's just a bunch of engineers that are all working and are to some degree full stack thinkers, but are, it's very engineering focused. So there's no one answer. I haven't quite figured it out yet. I do think the pirate architect configuration for new things is really helpful. But what do you guys do? Yeah. Well, we have something similar, but it's not actually on the role. So for, for any kind of new feature, we, we have this idea of stages. So like the first stage is like shaping. So it's, it's, and we're, we're influenced by the, what's the shape up. Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha Haha a lot more dated from like the features that they use as examples, for example, that they're talking about building. But some of the ideas I think are really sound. So we have this idea of there's like a shaping phase where what you want there is you want to 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 you would like the user to hire us to do, right? And it's like, okay, this is the job. What are possible shapes of that solution? And you go and you explore those shapes as quickly as possible. And then you kind of look at those and you have to be very honest with yourself and say, if we spent time on this, do we think we could actually, like, would people actually hire us to do this or not? Right. And so then, and then we have a next phase, which is like kind of validate. It's like, okay, we think we can like prove it. Like for a small, a small number of people, like just 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 actually make this 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 yeah, but so that's just one of those open questions. I mean, you have, you know, 60, 70 people. So you, you have had to answer that at least provisionally. So what is the structure that you've come to provisionally? We're still, we're still messing around with it. Like we, we still have like, we still have titles and I don't know if we should have them. Like we have, you know, you're a designer, you're a PM, you're an engineer. Right. And I always, I mean, I'm always flirting with the idea of killing those. How many PMs do you have? Four, three, depends, depends if you count me. Yeah. Yeah. I wouldn't count you. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. And like, yeah, I've always flirting with the idea of like killing, because it's like, what you really want is on this project right now, someone needs to do certain types of things. Like someone needs to own like the aesthetic or the user experience and someone needs to own like the building and that could be the same person, or those could be two different people. Right. And someone needs to own, like, what are we trying to do here? And what's the strategy? And like, what are the next few things that we need to hit in order to hit that? And, but then it's just like a lot of communication overhead if you don't have roles, right? It's kind of like, okay, well, what exactly are you going to do versus what am I going to do? Maybe it'll all be agents one day, who knows? We'll, we'll, we'll keep experimenting. Interesting. Well, one of the things that you said when we were just about to start recording is you spend most of your time in granola. And so one of the things you're curious about for me is if I'm playing around and experimenting, like, what am I, what am I finding? So I want to let's talk about that. I think there's a lot of meat there. First of all, tell me about, tell me about that. Like the, I spend most of my time in granola. I think that's a, it makes perfect sense, but also as a, as a CEO, as a strategic way of being, tell me about that decision. So like I mentioned before that I think, uh, the big opportunity here is to kind of invent how we're going to work and collaborate with AI to think and do things right. Like that, that's kind of in some shape or form, I think that's what we're all chasing right now in Silicon Valley. Right. And, um, and to that end, I think there's a lot of, um, that's the kind of thing you can like think about abstractly, but then you have to be playing with to, to, uh, to kind of get a feel for. And, um, it's just, it's hard for me to have the brain space of, of playing with every new thing that comes up. Right. And in, in granola, we have a lot of, a lot of context and a lot of internal tooling so that I can play around with different ideas, but they're oftentimes like in, in my little universe, as opposed to like, I don't go and set up very complicated workflows in, in Claude, for example, like I do it, I play around with it to get a feel, but I don't, I don't, um, those aren't load bearing for me because I, I'm trying to see what makes sense or doesn't make sense to do inside of granola as we paint that future picture. It seems like you are at the forefront of experimenting, trying new things, building different workflows for yourself. So like maybe just start off by being like, what's the current state of, of Dan's like tooling stack. And then we can go from there. I spend all my time in codecs. Okay. Almost. How long, and how long has that been? Like, is that a recent thing? Is that like two months, maybe two, three months. Okay. Um, and then, and I, and I do use the Claude desktop app sometimes, like when Fable was a thing, I, I track all my usage. And when Fable was a thing, you can see me like go on Claude usage. And then when I, when it left, it went like down. Uh, so I assume when it's back, cause I think Fable, Fable is just a different beast. And I test all the new stuff and I have access to stuff before it comes out and Fable is just different. Um, but I think of, so my, my overall view is that work is bifurcating into two surfaces. Um, one is async delegation work that happens in Slack. That's co collaborative multiplayer, um, sometimes proactive. And that happens with Slack bots. Like we have one called plus one, there's one called Victor, there's the Claude's tag. And that's very much like, um, okay. Every morning it posts in a channel and says, Hey, here's all the bugs that got solved. Here's all the bugs got reported. Here's all the, here's all the PRs we pushed. Um, and then you can add it and say, can you, you know, kick off, can you kick off PR for, you know, XYZ bug and it just does it. Or can you, uh, we're trying to name this new product. Can you, uh, read all the stuff we've said about what we want the product to be and then propose some names. And then the team can be like going back and forth with it in the same channel, um, to, to talk through names. So you can hand off stuff with it like it's a coworker. And importantly, cause most AI right now is single player. You can do it, you do it in public. And I think that's really interesting in, in a whole set of things. However, however, for serious work, you can't, you're always going to get more out of it. If, if you have a, a better collaboration service between you and the agent and Slack is not good for that. And so the other surface is something like a codex or, or a cloud desktop app where you and the agent are sitting in the same place on the same app together. And in particular in codex, for me, it's like, I use almost all of my software in the in-app browser of codex. So I'm bringing codex into my email or into, you know, whatever, whatever it is in the same way that, what do you mean by that? Can you, can you describe that? How do you do that? I'll explain. So, you know, like, you know, when you're building something in codex or cloud code and it opens it in app browser and it lets you see the local host version of the thing and you're iterating on it. Basically like all of the patterns, a good mental model for how AI works for me is all the patterns that started with developers or builders eventually make their way into all of knowledge work because we are, we, what we found is that building a, um, building a good enough agent to build any kind of software. Once it can build any kind of software, it's actually really good for doing any kind of knowledge work that you want. And that's like the last, that's why cloud code went to cloud co-work. That's why, you know, codex is now all of knowledge work, all that kind of stuff. So one of those patterns is when you're building something like an app, um, what you really want is the agent to be in the loop with you. So as it builds something, it opens an in-app browser, you can see it and you can kind of go back and forth. You can annotate it, you can whatever. And you and the agent are seeing it together. Uh, that pattern also works for any kind of software. So any kind of website you might visit. So really simple example. Um, last night I, uh, I moved departments recently and I needed to change my internet and I just told codex, go figure that out. And it knows the address of my old one and my new one, which is actually the same building. I'm just moving floors. It just opened up the Verizon website and it's in app browser. And it logged in. I gave it the password. It logged in. I gave it the password. And then it opened up a chat with a customer service agent who was also probably using AI. And it just like chatted with them until it switched my internet. And it also like, and all these little things come up where it's like, okay, when do you want to move in and out? And codex knows because I've been talking to it about like when I moved and when I wanted to switch. Um, and then it's like, here's, here's your old plan doesn't work. Here's the new plan. Um, and codex, codex knows to be like, I don't want any hidden fees. It knows how to do the math on, you know, is this a good deal or not? And to be able to research it and then to like push them to give me the thing that it thinks I should get. And I don't have to do any of that. I'm just like sitting there. And is that, is that something that you somehow communicated to codex or is that just like an out of the box? Like obviously any human would want this when talking to an internet provider. It's, it's both. It's easy because it's, it's easy for it. It will, it, it knows pretty well when it can make assumptions and when it, when it shouldn't. Um, and so I'm, I can be in the loop on it and I also can just go out, go to another thread and be doing something else. So I'm kind of like flipping back and forth with it. I think that's something, but, but it's, there's a more, there's a more general thing there where I use, this is how I do my email. Um, it is in the loop with me in Quora, which is our email app. And, um, also I have this, this, this open source thing I experiment, I built called tend, but basically it's like my emails are now cards that I read in codex in the in-app browser. And then each card, it says, here's what the email said. Here's what I think the draft should be. Do you want to send it? And I just talk to it. I see. So, but this is, this is basically you've like vibe coded your own email client basically, right? Is that I've, I've voted an experimental email client that does this. And then we will have a, we will have a version of Quora, which is our full email client that just has this out of the box. But you can think of the apps that, that are structured this way as being, um, I've been calling them codex native apps, but they're basically apps that are responsible for saving the state and rendering the UI and you bring your agent to it. And I think that that is a much, it's a, it's a very powerful paradigm because think about, I mean, think about all the work that you have to do for granola to like make an agent that is good. And it's, it's really hard. And you're also, you're also competing with the clods and the, and the codexes of the world who are also building the same kind of agent with the same kind of functionality. Um, and to some degree, I also think that, um, in some cases that's, that's, that's very worthwhile. Cause I do think two agents is 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, how everyday work gets done, how much ground you can cover and how fast a team can scale to stay ahead. You need tools that give you a competitive advantage built for this new era. Adio is the CRM for the agent native world. It meets you where you work, compounds every customer signal into context, and then acts on it across your pipeline to let you move at unmatched speed and scale with agents and automations for every job. Adio orchestrates your work around the clock. We use it internally at every, and we love it. It's built to handle the scale of your workloads. It's extensible with an API and MCP access, and is built with infrastructure to keep up with your most ambitious agents. It's loved by high growth startups like granola modal whisper flow and every adio runs the work behind every win that's adio the agentic CRM go to adio.com slash every and get 15% off your first year. That's adio.com slash every. And now back to the episode. What do you think, like, yeah, you keep saying that, and I'm really excited about that idea. I wonder how does that work in practice? Like if, forget granola, but like, you know, it's like, let's say you, I don't know, can you do this with Quora right now? Or like, how, like, how do you build it? How can, how could we build an app that would allow you to bring your own agent? That's not, you know, MCP. Cause it feels a little bit different, right? Cause it's like, you still want to have the UI that like, that's the difference. It's like you and you and the agent are both looking at the same UI and manipulating the same thing. MCP is part of it. Um, but yes, I think MCP is you're historically, you're thinking about it as the agent is going to interact with the app and I'm not going to interact with the app. And what I'm, I think what this paradigm says is actually you want your agent and your, and your, and the user to be interacting with the app at the same time and be able to trade off. And so the way that you do that is one, yeah, you give the agent access to an MCP or a CLI. And then you give the user access to a web interface and the user is using the web interface inside of an app browser of a codex or like a, or of a, of a cloud code. And then the agent can decide, do I want to, uh, help the user or collaborate with the user via using the browser use or via using the CLI, which I think CLI is somewhat better, but the, the trick is the CLI has to then modify the state of the UI. Right. Exactly. That that's the thing. It's like, that's the thing that needs to be. So it's almost like, uh, if you had hypothetically, let's say you had an, you could have an MCP, right. That actually, uh, had a state full, like the MCP could modify the state, like real-time state of like a UI that was rendered for a user. And ideally there was like, at least a one-to-one mapping of anything you can do in the UI could also be done through the MCP. So you have like an agent and a human interface. Cause like, um, computer use or like, it's like the web browser use feels like, it's unnecessarily slow, right. It's like, it's a hack, uh, and not, not, yeah. Okay. That's really interesting. Um, yeah, there's, there's something about the presence of the agent. Like this is, this is, I mean, this is a fascinating topic. I haven't, I haven't thought about it very much, but it's, um, the embodiment of the agent is also maybe interesting, you know, it's like, uh, you know, when you're in Figma, you can see other people's, uh, like locations on the, on the canvas. And there's, there's something there that you would maybe would lose if there was just like an MCP and the human, like, maybe, maybe not, I don't know how you, how do you feel like, is it, do you, is the, does the agent just feel like it's just the computer and you know, that's all the same, or does it feel like it's an entity that you're like, you know, you're both looking you're both looking at the same thing together. That's that it's more that it's, it's in the same way that with the Google docs, like we have this markdown editor called proof that we built. And like in that one, you can see codex has entered the document and you can see where it is. Oh, that's cool. How do you do that? How do you, how does codex enter the document? It's just the, um, this, the same kind of, uh, CLI MCP type, uh, type situation, but it has a command that's like, okay, set presence, um, set location in the document, that kind of thing. And agents are very good at knowing how to do that. But there's, there's so many interesting then UI challenges to figure out because an agent can do like a thousand different actions at once. And so how do you show that to a user? It's interesting. That's, that's actually not where my brain went. Cause like, you're right. It's like, yeah, it's like, if, if you want to see what the agent's doing, that's one problem. I was just thinking in like an email, it's like, it'd be nice for it to know where your mouse is. It'd be nice to be able to like, sir, you know, just be like, oh, this part of the email is not great. And just have that be, you know, either you highlight the text or whatnot. And that's not really possible today, unless you explicitly, like, how would you have to do that? It would have to be like, looking at pixels on your screen, right? There's no native way to do that unless you build it into a UI and you're like passing that information to the agent, right? More or less. I think the way that the way that I do it is each, so each piece of information that I want to do, want to take care of is represented in a card. And then I can talk to the card. I can say like, uh, yeah, it doesn't, it doesn't necessarily know where my mouse is, but it knows that I'm talking to this part of the UI and then. And it just knows because you say that when you're talking to it or because that is the main thing that's foregrounded in the app? Whatever I'm looking at is currently focused. And so, and I know that it's focused. And then when I'm talking to, it just knows to put, to put that context next to that thing that I'm looking at. Okay. That makes sense. And you're, this is, you're actually speaking, right? This is like, you're using monologue or whisper. Yeah. Using monologue or something like that. Right. Yeah. That's sort of my view of, of work and how things are going. And we've been talking about, okay, there's this word there, the prize is there's a new way of working. How does that fit into or differ from how you've been thinking about it and your strategy for granola? I don't know. I took, I was, I took this like class once and they, they were talking about the difference between, uh, complex and complicated problems. Have you heard this? Yeah. Yeah. And it's like, uh, complicated, it doesn't mean it's gonna be super hard, but it's like, it's kind of knowable, you know, it's like you, you, and versus complex problems, it's unknowable. You have to like, probe the system and kind of see how it reacts and like go from there. And, um, uh, so I, I think we're very much in a complex problem space here. So I don't, I don't have like an overarching theory of where this is all going. I think I could make one up that would sound plausible or as plausible as the next person's. Uh, but I'm more in the mode of like, what are, what are things that, what are insights or nuggets? And I'm like, Ooh, okay. I've, I now, this is like a thing that I've learned. Uh, and now I believe to be true and I'm gonna, I'm gonna carry that with me. Um, and so I have, I have a few of those. Like one is, um, it seems like one fundamental design challenge in like this agentic world is the time traveling problem. Basically like agents take time to do things. And therefore like when you, you're talking about Slack as an interface for this, which is like the async delegation problem, I think you said before, which is basically like the moment in which you kick off a task and the moment when, which you're reviewing the task are disjoint. And then you need to get all that context into your, into your head. And I think that'll be one of the, I think you'll see a lot of, um, the interfaces that evolve to be highly optimized for that. And I haven't seen anything that's great to, to be honest. Like, I don't know, I like the conductor. It's like, Oh, I've got all these different like chat threads and I'm jumping between them when it's kind of ready. Like, it feels like there'll be, I don't know what they look like. There'll be evolutions be, you know, beyond that, that are coming. Um, another one that's been, that's interesting. Like another way to get around this, like, it takes a while for an agent to do thing problem is, um, pre-process a bunch of stuff. Like if, if like, uh, so like granola, like one thing that we figured out is like, if I ask granola to do something and I have to wait 20 seconds, basically humans will rarely wait for 20 seconds. If they're in the like back to back meetings, chaotic, crazy workday, which is kind of the user that we're thinking about. Um, but if granola kind of thinks about something you might want and then pre-generates it, and then at some point might be like, Oh, here in case you want this, it's already here. And all you have to do is click on it. That's like a, it feels completely different. Um, and so like, uh, we have, we have some examples there. Like, um, we launched this thing recently where granola will try to generate a brief for you before a meeting where it's basically, here's this person you're meeting with. Here's the context of like, like who the person is, if it's a first meeting or, or what you guys talked about last time, if it's a, if it's a, another meeting and this one, you essentially have to pre-generate it. Cause it's, it's, it's useful when you're running two minutes late to a meeting and you're like, wait, who the heck is this person I'm talking to again? Like, and, and like, that's the, that's the critical moment. So you really only have like a 15 second window where it needs to be there or it's kind of useless. Um, so we, we actually pre-generate like millions of, like we pre-generate a silly amount of these, um, for a small percentage of them actually being like, opened. In the belief that when you do open it though, you really, really appreciate it. Cause it's like, right. It's exactly what you need in the moment of need. Um, it's like an interesting, it's like a, it's a, it's an interesting process or trade off there, especially from like a cost perspective. Cause it's like a, you know, we're like hours and like, I don't know, hundreds of thousands of hours of like agents reasoning about things that may or may not ever get to see the light of day. And how do you, how are you measuring that? Like the, whether that's worth it or not? It's an open question. Um, I don't know how to measure it just yet. What I'm trying to figure out is that we don't have a good metric between that. Like there's, there's use, like if something's not used at all, it's obviously not good. Right. But then there's like, if something is used a little bit or, you know, a decent amount, but it's really load bearing when it's used and that's still very valuable. I'm trying to figure out how to, how to measure what that is. Right. Like I was at a, I was at a founders conference, uh, the other day and like four founders came up to me and, and, and talked about this pre-meeting brief feature, which like surprised me because it's not, you know, it, it's not used as much as like proportionally. That's not what I would have expected, you know? Um, so yeah, we have this, um, with this, uh, uh, analogy, um, metaphor. I always forget which, which of those suit is inside of granola of like, um, how we want the granola product to, to feel. And it's, um, it's like a handrail. So if you imagine like stairs, like all stairs have handrails, right. And yeah, it's like, basically it's like, you never notice a handrail, it's like invisible, but like that, that moment you trip, like your hand like shoots out and it needs to be right there and it needs to be load bearing and it makes stairs way safer. Uh, and that like, that's how we think about granola, right. We kind of want to get out of the way until you really need us. Um, but yeah, we, we probably need better, better metrics or frameworks to like measure. One thing we, we would thought is like, if we just take it away, like if we take it away from a number of users, like how much do they shout or like, what kind of, what's the impact of us doing that? But even that has, it's not, it's not the best way. Or maybe making like seeing if they will click to like generate, click to generate, as opposed to here it is. And it's already generated, but you know, would you take the proactive action to do it? Of doing it and then it's, and then it's there. Yeah. Yeah. But then once, and then it's like, okay, they do then, are we always gonna make them click? I don't know. It's like, uh, like, I, like we could do it as a test, I guess it's, it's, it's, it's, yeah, it's a tricky one. That is tricky. What, um, well then how, how, then how do you think about also what is granola's role versus the codexes and the co-works of the world? And, and what do you see as being places where you want to integrate and make yourself available to what they do versus places where you're like, I, I want to own this. This is like something that we can uniquely do well. Yeah. So my view here is that, um, it's like a new, again, it's like this, this new era of computing where, uh, for the first time computers can make sense of our context and, and you can do amazing things with that. Right. And, um, and to that end, the having the right context is really critical and you being able to, to get value out of AI. So, uh, my belief is that, um, the context you have in granola, we should, it's like, we should make that as available to as like, however you want to use it. So, um, if you want to use it in codex, if you want to use it in your personal agent, if you want to use it, like whatever you can do that, if it can make your life better to use granola context, you should, and we should make that really easy. And, um, there's a lot, you know, our, our API or MCP, uh, is going to get a lot better over the next couple of months because like, that's like a, a, a, a first class goal of ours. Um, I think there are a number of jobs to be done, pain points, use cases that we should just be five X better than anybody else in the world at. And, um, and those, the, the obvious ones are all related to meetings, right? It's, it's just one of those things where, and maybe, maybe, maybe you feel differently. Maybe you're more AI pilled than I am. Like, I think that the, the models are going to keep getting better, but I think that, um, if granola just cares about a few things way more than anybody else, and we optimize the hell out of those things, they'll just be a better experience, especially if they're like tied to a UI that you have to use in vivo, like during a meeting, for example. Um, and so that, that's like our current strategy. It's basically be best in the world and anything that's like meaning adjacent and then make like the, be the best way to capture context, to power any agents you have. And, and that sounds, I can give you an example. There's like, um, I was talking to, uh, I was talking to a user and they were doing something really clever. She was, um, uh, she worked in sales and they basically used, I think it was Claude, to generate a microsite before they would talk to a potential client. And the microsite was, it was really impressive. They had this template and then of what that microsite would look like. And then, um, given a new potential customer, they would, uh, Claude would like style that template to look like the customer's website. And then they would connect the granola MCP and just pull all the context from granola and like fill out all the data and the fields and the widgets based on that data. And that's just the kind of thing that we would never try to be best of the world at and wouldn't make sense to. Right. Um, but, uh, she would also be, um, in her case, she was like writing a lot of emails in granola right after meetings, cause like follow-up emails and granola made a lot of sense for her. And that's the kind of thing where it's like, maybe we don't, we don't want to write every email. We don't want to be every, we don't want to be your email inbox, but there might be a type of email that you want to send right after a meeting that is like, you know, extremely good on certain dimensions that we could be the best in the world at. And like, it makes sense to do both. I don't think it's a one or one or other. Um, I was undecided about this two years ago when we started Granola. Now I have, I have, I have strong conviction, but it kind of took me a while to like figure that out. That's interesting. Yeah. I think from a user perspective and I may not be your core user. And that's actually really interesting to me to like, to like learn that. Cause one of my, one of the, the thesis that, that we're building every round. And one of my convictions is what builders do now, people who want to like figure out these general purpose tools and like build these workflows or whatever regular people are going to do in a few years, once they're more built in it, once it's built into the handrails of these products. Um, and so what I do is I just like play around with stuff and try to figure out, oh, this is what I use codecs and Slack agents and whatever for. And eventually that will make its way into maybe stuff that we build, but stuff that the labs build or stuff that other people build. And we get to see it first. Can I ask a question about that? Cause I think, um, is, is the theory that, uh, so the stuff that you are trying to automate with AI or the interactions you're trying to build, do you think that other people will also be building their own audit, like, like more, like less AI forward people will be building their version of those automations or do you think those will be productized? Yeah. Okay. We have, I have the same view. So yeah, I think you're the guinea pigs, right? So basically like, yeah. And we have tons of Guinea pigs using granola, right? So it's like, uh, like my view is basically we should just look at what are, what are the most common and cutting edge ways in which people are using our API and MCP to do crazy stuff and then figure out which of those do we think, uh, we could be the best in the world at. And a lot of users would benefit from, and then build like a really beautiful, seamless product experience that might've taken, like I was, um, I ran into the founder of one of the founders of hugging face the other day at a conference. And he was like, man, I had built this super convoluted, complicated pre-meeting brief workflow in, uh, cloud code. And I'd been working on it for months and I, I, I just turned it off because yours was, was better. Uh, you know, you know, and that, and like, and to me, that was like, that's exactly what I want. And I can't do this for everything, but that's exactly what I want because we're just going to care more than any individual should, should ever care about any one workflow is, is kind of how I think about it. I think that's exactly right. Um, okay. So we're, we're, we're definitely aligned there. My current feeling is in general when I, and this is, again, this is just for me and, and, and this may change, but when I see granola, like a, like the UI come up, 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 that I want to access it is going to be it pushing something into codex, which is my work surface or codex pulling something out of it. And, and I think this focus on meetings is so right. And it's actually such a hard and deep problem to just get that, like the context of that, right? So for example, I mean, you know this better than I, but I'm just thinking about when, when we do, when you do a transcript and I say the name Chris, which Chris are we talking about? Right. Um, and so I sort of, I think of the, the job of software companies in an AI world, AI is this really super flexible thing, but it's only flexible if it's given the right structure and the right context within which to be flexible. So if, if, you know, AI, if we're using the human body as an analogy, AI is like the, the ligaments and the muscles, and then the software has to be the bones. Um, and the bones sort of set, like give it form and, uh, a structure, but then the, the AI can kind of like work around that to, to, to do anything. And, um, there's so much for, even, even for example, again, in a meeting transcript, I might say, um, that's a good idea, but the way I say that means, says a lot about what I actually think that is not captured in just a transcript. And I want granola to be, uh, like I, I have a, I have this, um, this automation that runs, uh, that turns all the slacks and all the meetings that I was not in into cards that I just go through and I can see things that happened in the company, but the transcripts are a often wrong and B they, they capture none of the nuance of how and why things were said. And I think that 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. Um, and maybe, maybe like for, for a more normie user who doesn't want to be in codex all the time. Although I do think that that's, that's going to be more and more the case, like you still want to have the UI, but there's all this background context processing that I would look to you guys to do that. I don't really want to do. Yeah. Yeah. Yeah. No, that makes total sense. I think, um, I guess the transcript is one way to capture the context from a meeting, right? It is the, the simplest way. And there's, LMs are weirdly good at making sense of garbled transcript transcripts and doing something useful with that. Um, I think, but what's the actual job to be done here? It's actually like, what are the insights or what are the decisions or what are the actions I need to take on top of this context? And that there's this layer of, um, intelligence, um, or interpretation, which is like the, the disambiguation, like, which Sam did I mean is like a, is like a great example. Um, we have this, uh, so we have this, um, I'll give you like, there are challenges. It's such an interesting space. So here's a challenge we have, right. Um, 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, we, we have this, but we, we don't use it yet. And I'll explain why generate a, a, a pretty, um, high fidelity picture of like who you are, what you're working on, what you're trying to achieve, what are your challenges, who you're working with on different things on. And let's just for, for, for argument sake, let's say this like a, a two page summary of like who Dan is today, right? The state of Dan today and it changes every day and we can generate better notes if we pass that context in this part of our note generation pipeline. Um, but now those notes might include information that didn't come from the meeting. Right. So like when you said it's like, oh, that's a, that's interesting. Or what was your example? It's like, oh, I like that idea. And like, we might be like, Dan doesn't actually like that idea. He thinks that's a terrible idea. Cause we know he hates that general class of idea. Cause he said that five other times and five other meetings. And so then there's this interesting question of like, who's the, like, who's the audience, right? And like today, a lot of people still, they'll use the notes for themselves, but they'll also, there's this mixed use with also share it with other people. Right. Um, whereas like the perfect notes for you are actually probably a little bit different or the perfect, like notes are just one. Um, it's just one way to represent that information. You know, there's like other ways. And it's like, what level of intelligence or interpretation would you, do you want granola to do? Yeah. But yeah, I, I totally hear you. This is why I think it's, it's a infancy days for us. Yeah. Or honestly, like you seemed really stressed in that meeting. Do you want to talk about it? Would be really, really interesting. Like maybe people would be freaked out by that, but also one of the things I use granola for a lot is like management stuff and being like, how do I do there? Or someone, someone on my team had a difficult conversation with someone on their team and they're talking to me about it. And I'm like, let's talk to Claude about the meeting transcripts so we can decide what to do. All that kind of stuff is in order to do it well, I need not just the transcript, but there was a long pause after XYZ said this thing. No one said anything for three minutes that you don't see that in the transcript. No. Yeah. Stuff like that is just, there's so much like richness there to be had that granola, to me, I want granola to do for me. Yeah. That makes, that makes total sense. Yeah. I also think, I'm curious, what are all the main ways? Cause he was like, I don't want to see the granola UI. I want to like pull that in codecs or whatnot. And I also wonder, okay, what are the main workflows or reasons why people are pulling transcripts or meeting notes into their agents and which of those, if you were to optimize around, you would do a better job at and which of those are like the long tail of like, you know, give people power and they'll do a better, a better job is also an interesting question for us. Yeah. What is on your mind for the next like six to 12 months as, as these models, like, okay, you saw Fable come out. Does that affect your roadmap? Does that affect how you're hiring or how you're building? Yeah. Tell me about that. The order of operation, the questions that go through my mind is first, like, what does, how does this change how we build internally and, and how do we structure our teams? Like, that's the first question. I think our roadmap is, and this is the kind of thing where it's like, you know, you can have one plan in the abstract and then you actually play with something you should, you should adjust it. And I unfortunately didn't play with Fable enough before it got, before it got yanked. But like the roadmap is more, it's kind of baked into the roadmap a little bit more, which is like, okay, models will get better. Here's the general strategic direction. And that's more like, I think our strategy is more dependent on what people use us for and what are the jobs to be done or use cases around that, that we can tackle. And model intelligence doesn't affect that directly too much, if that makes sense. Whereas model capabilities do affect how many people do we staff on a, on a, on a pod, you know, like what, like how, how do we define goals there? Like, like, should we be, should we be approaching things completely differently? So yeah, that's the thing that's on, that's on my mind for sure. The other thing is I, I think, so maybe this touches on a little bit like, like it's the stuff that you're using codecs for. I think there's some, I think there are, there's one or multiple canonical UIs that haven't been invented yet that are like right now, so Grinola, you have meeting notes, right? And you can use meeting notes or transcripts or context for lots of things. Usually when you're trying to make use of that context, it's not per meeting, it's usually you have a, a set of contexts. In our case, let's just say it's like all the meetings you had today or all the meetings you had this week, and maybe it's actually all the meetings and all the Slack messages and all the emails, but let's just keep it to meetings for a second. At that level of altitude, what is the right UI and interaction pad, uh, uh, interaction like design to manipulate or work with that context? I don't think anyone has figured that out. And maybe, maybe, maybe you have, maybe you're cooking on something Dan, or maybe you'll figure it out. But like, when I look around, I'm like, I've seen very little actually. Um, and, you know, coming up with new UI paradigms is it's like very hard and, and, and it's very rare for new ones to, to stick around. I think they're more discovered than invented, if that makes sense. Um, but there's a very clear gap that I see there. Like we have like a chat UI and chats, chat threads are like super valuable, like actually surprisingly versatile and powerful when you're doing one thing, but when you're actually trying to do multiple things across varied contexts, like, I don't think we have the right, the right metaphor there. Um, so that, that's something that's very much on my mind. Um, cause when you talk about the normie user, like, I think you're gonna need a simple metaphor that the normie user can just grok and interface with. It's not gonna be the kind of hoops that you currently, you know, jump through with, with, with codex. Yeah. Yeah. Um, how do you think about token spend both on your team and in the product? I think, um, okay, I'll do team first. So token spend on team. I think folks on the team should be using AI to, um, augment their abilities as much as possible. I think it's silly to say, to, to, to say, if you aren't spending this many tokens, then you're doing it wrong. Like, that's like a, I feel like a weird way to do it. I, um, I kind of trust the team to take the spirit of the goal, which is like, be the most productive, productive you can be, and, you know, be thoughtful about how you use it. Um, we didn't even track token spend like we're until like last week, uh, internally, just because it wasn't, it wasn't a priority, um, for me in terms of, uh, token spend in the product. Wait, wait, wait, wait, before we get there, did so you, but you started last week. So what did, what spurred it and then what did you come to? Fable. Uh, well, what we, basically what spurred it was like, do we even know how much we're spending or like, we should probably know how much we're spending. It was, it was, and, and there was, it was basically because folks are using Fable and someone's like, I think I spent a couple thousand dollars today. And we're like, okay, maybe, maybe this is something we should, we should at least be aware of. We did like literally the same thing when Fable came out and Kieran, uh, who runs Cora, he was like on track to spend like a million dollars in credits, uh, in a year, in a year, in a year. And we were like, okay, we need to figure out. Maybe we need to think about this a little bit. Yeah. Yeah. It actually could be worth it. And also we need to think about it, you know? Exactly. Yeah. Yeah. Um, I mean, this goes back to like, you know, things always outside of our ability. It's just one of those, like, it's like, oh yeah, we should probably, we should probably at least know how much we're spending. That sounds like a really obvious thing, but it's just like, we're just so busy with so many other things. It's like, now, now's the time. Uh, in product, I think, um, like I'm still a believer that, uh, it's early days and we have so much to gain by figuring out what are the killer kind of AI native experiences, uh, that Granola can, can, can build. And therefore, um, we're not very cost conscious on the token spend. So like I said before, like we pre-generate, I don't know, millions of, um, these briefs, even if only like 10% of them get opened because we want to like figure out what's that right experience for the user. And our belief is both costs will go down over time and we can optimize costs once we know what the best experiences are. So like that's, that's been, that's our philosophy. Um, agentic features are really expensive. Um, and so as we build more and more of them at some point, that'll, that'll, they'll break the math, uh, for us. Uh, but, but for now that's been the priority. And how much are people using true agentic workflows in Granola? I asked that as like a, I'm really curious about normie users learning how to use like power features like, like those. It's the word agentic that's tough, right? Like I think that like, um, roughly half is the answer, right? Like weekly, like, like every week about half the Granola users use us in an agentic way. Um, and, but I don't know if they would describe it that way, if that makes sense, right? Like they have, they, they'll be like, they'll ask a query that is like a kind of a complex query around, uh, um, you know, like, let's say your, your coaching or improvement question work that will look at a series of meetings over time and then do several steps like of analysis over that, right? Like that kind of thing is, is, is roughly half a week. Yeah. Really interesting. Um, Chris, if people are looking to find you online to use Granola, where should they find you? Oh, um, I don't know. So Granola, Granola's, uh, Twitter handle or X handle is meetgranola. Uh, mine is CJ Pedregal. So CJ, my last name. Um, and I, yeah, I guess those are the best places. Amazing. Uh, I always love talking to you. Uh, love what you're building. Thanks for coming on. We got to do this more often. Yeah, absolutely. I, whether, whether it's on, uh, on the pod or, or just, uh, just us chatting. I, I really enjoyed these conversations. Sounds great. Oh my gosh, folks, you absolutely positively have to smash that like button and subscribe to AI and I. Why? Because this show is the epitome of awesomeness. It's like finding a treasure chest in your backyard, but instead of gold, it's filled with pure unadulterated knowledge bombs about chat GPT. Every episode is a roller coaster of emotions, insights, and laughter that will leave you on the edge of your seat, craving for 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 yourself a favor, hit like, smash subscribe, and strap in for the ride of your life. And now without any further ado, let me just say, Dan, I'm absolutely hopelessly in love with you.