Simon Last: Broadly speaking, I'm really bullish on CLIs. I'm still bullish on MCPs in a certain environment. I think in particular, MCP is really great for when you want sort of like a narrow lightweight agent.

Sarah Sachs: I think there's definitely a lot of use cases where you don't want like a full coding agent with a compute runtime and also you want it to be like more tightly permissioned. MCP inherently has a really strong permission model. Like all you can do is call the tools. MCP is just like the dumb simple thing that works and it's pretty good. Notion is dedicated to being the best system of record for where people do their enterprise work. So we will always support our MCP in so far as other people are using MCPs, right? So regardless of our perspective, we've put a lot of effort into our MCP and we have a fantastic team that we're building.

Alessio: Before we get into today's episode, I just have a small message for listeners. Thank you. We would not be able to bring you the AI engineering, science, and entertainment content that you so clearly want if you didn't choose to also click in and tune into our content. We've been approached by sponsors on an almost daily basis. But fortunately, enough of you actually subscribe to us to keep all this sustainable without ads and we want to keep it way. But I just have one favor to ask all of you. The single most powerful, completely free thing you can do is to click that subscribe button. It's the only thing I'll ever ask of you. And it means absolutely everything to me and my team that works so hard to bring the Latent Space to you each and every week. If you do it, I promise you we'll never stop working to make the show even better. Now, let's get into it. Hey everyone, welcome to the Latent Space podcast. This is Alessio, founder of Kernel Labs, and I'm joined by swyx, editor of Latent Space.

swyx: Hello. Hello. We're back in the beautiful studio that Alessio has set up for us with Simon and Sarah from Notion. Welcome.

Simon & Sarah: Thanks for having us.

swyx: congrats on the launch recently. Custom agents. Finally, it's here. How's it feel?

Sarah Sachs: We ship things slowly. So, it had been in alpha for a little bit and at the point at which is it's in alpha. Um, there's a group of people that are making sure it's ready for prod and then there's a group of people working on the next thing. So, sometimes some of these launches are a bit delayed satisfaction. So, it's quite nice to remind yourself all the work you did because we do have a habit of like being two or three milestones ahead just because you have to be, you know, you can't get complacent. Um, but it's been great that people understood how this is helpful. And I think that's just easier in general building AI tools today than it was two, three years ago. People kind of get it. And so that user education um there's just it was our most successful launch in terms of free trials and converting people and things like that. It was really successful. So yeah, but there's a lot to build.

Simon Last: it was definitely super exciting for me because it's probably the fourth or fifth time that we rebuilt that.

swyx: And I mean, you've been building this since like 2022.

Simon Last: Yeah. I mean, like it was even right when we got access to like GPT-4 in late 2022. One of the first ideas we had is like, oh, okay, let's make an agent that we use the word assistant at the time. There wasn't really the word the word word agent yet, but oh, we'll give it access to all the tools that notion can do and then it will run in the background like like do work for us. And then we just tried that many times and it just was too early.

swyx: I need to force you to like double click on that. What is too early? What didn't work?

Sarah Sachs: We were find like before function calling came out, we were trying to fine-tune with the Frontier Labs and with Fireworks like a function calling model on notion functions. This is right when I joined. I joined because um we needed a manager. Simon was needed to be able to go on vacation. So uh that's that's around when I joined. So you can speak much more to it.

Simon Last: Yeah, we did partnerships at both Anthropic and OpenAI at different times uh to try to at the time the I mean when we first tried there wasn't even a concept of like tools yet. We we sort of designed our own like like tool calling framework and then we tried to fine-tune the models to to use it over multiple turns. Um and because it it didn't work well out of the box I think. Yeah, the models are just too dumb and the context length was also way too short. Yeah. Um and yeah, we just kind of banged our head against it for a long time. Uh unfortunately, it was always like there was always like sort of glimmers that it was working, but um it never felt quite robust enough to be like a useful, delightful thing. Um until I would say uh the big unlock was probably like Sonnet 3.5 early last year and that's when we started working on our agent, which we shipped last year. Um and then and then uh uh custom agents kind of a similar capability and that that one just took longer because we we just wanted to get the reliability up a lot higher because it's actually running in the background

Sarah Sachs: and the product interface of like permissions and understanding you know this custom agent is shared in a slack channel with X group of people and has access to documents that are surfaced to Y group of people and the intersect of X versus Y might not be whole and so how do you build the product around making sure administrators understand that permissioning took multiple swings.

swyx: Everything is RBAC at the end of the day. Yeah. I'm curious like when the models are not working, how do you inform the product road map of like, okay, we should probably build expecting the models to be better at some reasonable pace, but at the same time, we need to, you know, you had a lot of customers in 2022. It's not like you were a new company with like no user base.

Simon Last: Yeah. I mean, I think there's always the balance of, you know, like you want to be AGI pled and thinking ahead and building for where things are going. Uh but also you want to be like shipping useful things and so we always try to like like keep a balance there. You know, we we try to take like a portfolio approach. You know, we're always working on multiple projects and and we're always trying to work on, you know, maintaining things where they've already shipped like like shipping new things that are like eminently working well and make them really good and and then we want to always have a few projects that are a little bit crazy.

Sarah Sachs: Why what what changed over the three and a half years of trying it, right? Because most people always say like it didn't work yet, then reasoning models came, then it worked. I was like, okay, let's go a little bit. I mean, that's part of it, but I think the other part of it that I actually think is really what will set notion apart for every new capability is we have like two skills that are crucial when it comes to frontier capabilities. One is not letting yourself swim upstream. So like quickly realizing if you're just pressing against model capabilities versus not exposing the model to the right information, not having the right infrastructure set up. That in of itself is a skill of intuition. And then the second is to see okay you're not swimming upstream. Which direction is the river flowing? And what is like how do we think ahead about the product and start building it even if it's not great yet so that when it is there we're ready for it, right? And like those can sometimes feel like counterintuitive things like we can be trying to fine-tune a tool calling model when they don't exist yet. And the the trick is to not do that for too long, but realize that there was something there. And we've had a lot of things which like um were just like not swimming in the right direction with the streams. I think we had multiple versions of transcription before we got meeting notes, right?

swyx: I'm curious what are things today that maybe in 18 months people will like, "Oh, obviously this was gonna work."

Simon Last: I think one thing that's becoming more clear is I think like like coding agents are the kernel DGI sort of everything is a coding agent. I think that's sort of one one direction. Um, and then yeah, the exciting thing about that is sort of your agent can sort of bootstrap its own software and capabilities and actually debug and maintain them. And so, yeah, we're we're we're thinking a lot about that. And then, yeah, like like another category of things that I'm really excited about is like uh we call the software factory. Lots of people are using this this this sort of word. Um, basically just means can you create sort of like a as automated as possible a workflow for developing, debugging, merging, reviewing, and maintaining a codebase and a service where there's a bunch of agents working together inside and like like how does that work?

swyx: Is there a day there are no software engineers at Notion?

Simon Last: what does it mean to be a software engineer? I mean, I think the way things are going is like we're on some continuum where if if you look back 3 years ago, humans were typing all the code and then we had autocomplete. You're typing a little less of the code. we had sort of like filling agents filling lines and now we're getting into like agents doing longer range tasks where you can debug and implement a fix and then verify it works and you know get your get your PR even like like merge and deployed. I think we're sort of just moving up the abstraction ladder and then the human role becomes more about observing and maintaining the outer system. There's a stream of agents flowing through like merging PRs what's going off the rails like what do I need to approve? Is there like a learning or memory mechanism that that works? So it's kind of a hard engineering problem. There's a, you know, there's a lot to do there. I think we're just sort of moving up the stack.

Sarah Sachs: I think every software engineer at Notion this summer went through like this um shear um one of our engineering leads at the company called it like every software engineer is going through the the identity crisis that every manager goes through where all of a sudden they realize their ability to write code is less important than their ability to delegate and context switch and I think that that is a transition out of being a software engineer but yeah there's a critical difference to being a manager which is that like It is actually very deeply technical. The problem of you know humans are very like like like fuzzy and you you can't like treat a team of humans like a like a rigorous system where like you know PRs like like flow through and can be in like a blocked status and then what happens when they're blocked right with a set of agents you actually can do that and and I think it's actually there's a lot of interesting technical rigor that that goes into that. It's a it's a technical design problem ultimately.

Sarah Sachs: I show that thesis to so many candidates. Um, and by the way, like in the beginning, parts of what we build are rappers on functionality that works well, but that's not really the most um I would say that's not the product that that drives revenue and that's not necessarily always what users need. The analogy that I've been coming back to is data dog in AWS. Yeah. So, uh data dog could not exist without cloud storage, right? that it's kind of fundamental that that works. Um, and AWS has like a cloudatch product, but Data Dog is an expert on understanding how people want observability on the products they launch. And we're experts on understanding how people want to collaborate and that's really where our expertise lies.

Simon Last: notion has always been super horizontal and our our task has always been to sort of balance these two somewhat opposing forces of like we're listening to our customers and what they want us to build. It's a broad slice. And then also we're thinking about like okay, how do we decompose what they want into nice primitives that are that are really nice to use and will will get us like as much bang for the buck as possible and then you know maintain the whole system make it all like like super clean and nice to use.

Sarah Sachs: I think it's a real issue when people say evals and it's just like that's quality. That's like unit I mean it's like saying testing. It's not just unit tests, right? So, we have the equivalent of unit tests, regression tests, those live in CI. Those have to pass a certain percent you know within some stocastic error rate. Then we have as you're building a product eval of these aren't passing right now and this is launch quality. So we have a report card and we need to on these categories you know be at 80 or 90% of all of these user journeys to launch

Sarah Sachs: and then what we have what we call frontier or headroom eval where we actively want to be at 30% pass rate and that's actually been a effort that we took in partnership with enthropic and open AI in the past maybe two or 3 months because we actually hit a point where our evals were saturated and we weren't able to really give insightful feedback other than it wasn't worse and not only is that not helpful for our partners it's not helpful for us to understand where the stream is going. And so we spent a lot of time thinking about what notion's last exam looks like, right? Not just humanity's last exam, Notion's last exam. And um there's a lot of, you know, dreams about what that would look like. Notion's last exam is a big thing inside the company, and we have people full-time staffed to it exclusively. We have a data scientist, a model behavior engineer, and an full-time um evals engineer just dedicated to the evals that we pass 30% of the time.

swyx: What is an MBE?

Sarah Sachs: A model behavior engineer. Model behavior engineers started with a title data specialist before I joined when they were working with Simon on like uh Google Sheets and like Simon just needed someone to look through Google Sheets and say yes, no, this looks bad, this looks good. Right? And so we hired people with kind of diverse linguistics background. And over time we've built a whole team um with a manager who's now kind of reinventing what that role is with coding agents. So they used to be kind of manually inspecting code. Now they're primarily building agents that can write evals for themselves or LLM judges. moving forward it's this mix of like data scientist PM and prompt engineer because there's craft in understanding like even like what models can and can't do things how do we define like that headroom how do we define like what a good journey is um is this model better or not why is this failing there's some qualitative work, but then there's also like a lot of instinct and taste to it and that's not necessarily software engineering and so we have like very firm conviction and we have had for a number of years now that that is its own career path and we have always welcomed the misfits so to speak. So we really firmly believe that you don't need an engineering background to be the best at this job and that's what's quite unique about this particular role.

swyx: What is the design of the software factory that you're building?

Simon Last: Yeah. I mean I think we're trying a lot of different things. I mean ultimately you want to design a system that requires as little human intervention as possible but like still maintaining the invariance that that you care about. So yeah, we're exploring a lot of different ideas there. I mean I think I can talk about like a few things I think are important there. Like one thing I think is really important is um having some kind of like specification layer. You can just commit markdown files. That works pretty well. It's nice to be notion man. I'm just saying like the spec like the natural home for specs is notion. It can be a database of pages. Yeah. I mean it needs to be something that is you know human readable and and viewable and I think that's pretty key. Another really key component is like the the self-verification loop. You need a really really good testing layers basically. And that's a really deep uh problem, but but getting that right, you know, and then and then it's kind of like the workflow of like what happens when there's a bug, how does it flow into the system? Like is it like a sub agent working on it? How does it make a PR and how does that get reviewed and merge and then you know, so there's like the the flow or process.

swyx: And I'm curious how you think about composibility of these things.

Simon Last: Yeah. So I mean there's there's two ways you can compose. One way is by using like the data primitives. So you can, you know, you could give you have one agent uh be writing to the database and there's another agent that's walking the database. So that's that's one way that they can coordinate that's like a little bit more decoupled and works really well. Or you you can couple them. So I I think it's actually not released yet releasing it like next week is uh in the settings for an agent you can give access to invoke any other agent. I just I I helped uh someone internally the other day they had they had built like over 30 custom agents for for our go to market team doing all kinds of different things. Literally over 30 of them. And and now I'm getting 70 over 70 notifications per day with just the agents are blocked on various things. Uh and then I was like, "Oh, okay, cool." You know, the obvious thing to do there is to make a manager agent, right? that's going to sort of be another abstraction layer in between your your 30 agents. Uh so yeah, we we set them up with like a manager agent and then has access to invoke all the other agents and it's sort of like like watching and observing them and then it sort of yeah just creates a layer of abstraction. So instead of 70 notifications per day, it's like like five and then and then the manager agent can help like debug and fix any any problems with the

swyx: How do you design pricing, value based pricing based on the task and things like that?

Sarah Sachs: So, they are um the credits and payment structures associated with the token usage. reason that we had to make it not just throughput of tokens is that it's not always priced that way. Like our um fine-tuned open source models are served on GPUs, web search is priced differently. You know, if we were to host sandboxes, those are priced differently. So, we had to think of an abstraction above tokens. And it's also not just tokens, it's the token model um and serving tier trade-off, right? we wanted to um from the get-go commit to making sure that customers were getting the fair deal, not necessarily that we were making a ton of money off of it, but that customers were paying for what was reasonable. And also, you know, we're selling enterprise SAS, so if we sell credit packs, then you get discounts if you're an enterprise and you buy a certain amount of credit packs and things like that. So it also just helped the sales motion um work a little bit easier.

Sarah Sachs: particularly because our custom agents are using usage based pricing. We think of pricing as like the barrier of entry for use of our product and we're quite committed to making sure that it's not wasteful. Um not just because it's a bad deal for our customers, but it's also bad business. if we can have our agents properly execute code that calls on CLI deterministically, it's a one-time cost, right? versus constantly having a language model integrate with an MCP over and over and over and paying those like repeated token fees. what's actually been hard for us is to convince people that auto is not just our cheapest, dumbest model, but actually the model that's best for the task that you want to do.

swyx: Cool. Uh well, thank you so much. This is such a great deep dive. Actually, the chemistry between you two is amazing.

Sarah Sachs: That kind of reminds me, I remember once you very strongly reminded me, our job is to not make the best harness for agentic work. Our job is to be the best place where people collaborate. It's like our job isn't to build the best wearable to capture meeting notes. Our job is to build the best place where meeting notes live, right?

Simon Last: Yeah. So, basically, you're saying everyone else can just pipe to you and that's fine, right? Yeah.

swyx: Thank you.