Notion’s Token Town: 5 Rebuilds, 100+ Tools, MCP vs CLIs and the Software Factory Future — Simon Last & Sarah Sachs of Notion

Broadly speaking, I’m really bullish on CLIs. I’m still bullish on MCPs in a certain environment. I think MCP is really great for when you want a narrow, lightweight agent.

Sara Ma

Mm.

I think there are definitely a lot of use cases where you don’t want a full coding agent with a compute runtime, and you also want it to be more tightly permissioned. MCP inherently has a really strong permission model. All you can do is call the tools. MCP is just the dumb, simple thing that works, and it is pretty good.

Sara Ma

Notion is dedicated to being the best system of record for where people do their enterprise work, so we will always support our MCP insofar as other people are using MCPs. Regardless of our perspective, we’ve put a lot of effort into our MCP, and we have a fantastic team that we’re building.

Hey, everyone. Welcome to the Latent Space podcast. This is Alessio, founder, and I’m joined by swyx, editor of Latent Space.

Hello, hello. We’re back in the beautiful studio that Alessio has set up for us with Simon and Sara from Notion. Welcome.

Sara Ma

Thanks for having us.

Thanks for having us. Yeah.

1. Custom Agents Finally Ship

Congrats on the launch recently. Custom agents—finally, it’s here. How does it feel?

Sara Ma

We ship things slowly, so it had been in alpha for a little bit. At the point at which it’s in alpha, there’s a group of people making sure it’s ready for production, and then there’s a group of people working on the next thing. Sometimes these launches are a bit of delayed satisfaction, so it’s quite nice to remind yourself of all the work you did, because we do have a habit of being 2 or 3 milestones ahead. You have to be; you can’t get complacent.

It’s been great that people understood how this is helpful, and I think that’s just easier in general when building AI tools today than it was 2 or 3 years ago. People get it, and so there’s just less user education. It was our most successful launch in terms of free trials, converting people, and things like that. It was really successful. But there’s a lot to build.

Making it free for 3 months helps, you know?

Yeah.

It was definitely super exciting for me because it’s probably the 4th or 5th time that we rebuilt that.

Yes.

You’ve been building this since 2022.

Yeah. It was even right when we got access to GPT-4 in late 2022. We said, “Okay, let’s make an agent that…” We used the word “assistant” at the time. There wasn’t really the word “agent” yet. We thought, “Oh, we’ll give it access to all the tools that Notion can do, and then it will run in the background and do work for us.” We tried that many times, and it was just too early.

I need to force you to double-click on that. What does “too early” mean? What didn’t work?

2. Why Agents Were Too Early

Sara Ma

Before function calling came out, we were trying to fine-tune with the frontier labs and with Fireworks a function-calling model on Notion functions. This is right when I joined. I joined because we needed a manager. Simon needed to be able to go on vacation. That’s around when I joined, so you can speak much more to it.

Yeah, we did partnerships with both Anthropic and OpenAI at different times to try to solve this. At the time, when we first tried, there wasn’t even a concept of tools yet. We designed our own tool-calling framework, and then we tried to fine-tune the models to use it over multiple turns because it didn’t work well out of the box.

The models were just too dumb, and the context length was also way too short. We just banged our head against it for a long time. Unfortunately, there were always glimmers that it was working, but it never felt quite robust enough to be a useful, delightful thing.

I would say the big unlock was probably Sonnet 3.6 or 3.7 early last year. That’s when we started working on our agent, which we shipped last year. Custom agents have a similar capability, and that one just took longer because we wanted to get the reliability up a lot higher, since it’s actually running in the background.

Sara Ma

The product interface around permissions and understanding that this custom agent is shared in a Slack channel with a certain group of people, has access to documents that are surfaced to another group of people, and that the intersection of those groups might not be the whole group—that took multiple swings. How do you build the product around making sure administrators understand that permissioning?

Everything is hard at the end of the day. I’m curious: when the models aren’t working, how do you inform the product roadmap? How do you decide that you should probably build expecting the models to get better at some reasonable pace, while at the same time you need to ship? You had a lot of customers in 2022. It’s not like you were a new company with no user base.

Yeah, I mean, I think there’s always a balance. You want to be AGI-pilled and think ahead and build for where things are going, but you also want to be shipping useful things, so we always try to keep a balance there.

We try to take a portfolio approach. We’re always working on multiple projects, and we’re always trying to maintain things that we’ve already shipped, ship new things that are eminently working well, and make them really good. Then we always want to have a few projects that are a little bit crazy.

What are the AGI-pilled projects that you have today? I’m curious. You don’t have to share exactly what you’re working on, but what are the things today that maybe, in 18 months, people will be like, “Oh, obviously this was going to work”?

Sara Ma

18 months? Yeah.

18 months is—

Sara Ma

It’s a long time.

3. The Software Factory Future

There are a number of things happening. I think one thing that’s becoming clearer is that coding agents are the kernel of AGI. Everything is a coding agent. I think that’s one direction.

The exciting thing about that is your agent can bootstrap its own software and capabilities and actually debug and maintain them. We’re thinking a lot about that. Another category of things that I’m really excited about is what we call the software factory. Lots of people are using this term.

Basically, it means creating as automated a workflow as possible for developing, debugging, merging, reviewing, and maintaining a codebase and a service, with a bunch of agents working together inside. How does that work?

Sara Ma

If you think back to your initial question—why did this take so long?—I think something Notion’s—

I didn’t say that, but yes, okay, go ahead. You—

Sara Ma

Why—what changed over the 3½ years of trying?

Exactly. Most people always say, “It didn’t work yet, then reasoning models came, and then it worked.” I was like, “Okay, let’s go a little bit—”

Sara Ma

That’s part of it. But I think the other part of it is really what will set Notion apart for every new capability. We have 2 skills that are crucial when it comes to frontier capabilities.

One is not letting yourself swim upstream—quickly realizing whether you’re just pressing against model capabilities or whether you’re not exposing the model to the right information or you don’t have the right infrastructure set up. That in itself is a skill of intuition.

The second is seeing, once you’re not swimming upstream, which direction the river is flowing. 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? Those can sometimes feel like counterintuitive things.

We can be trying to fine-tune a tool-calling model when those models don’t exist yet, and the trick is not to do that for too long, but to realize that there was something there. We’ve had a lot of things where we just weren’t swimming in the right direction with the stream. I think we had multiple versions of transcription before we got meeting notes, right?

Oh, I’ve got to talk about that. Yeah.

Yeah. I think we really closely partner with the frontier labs on capabilities, and we also have to have strong conviction as those capabilities move. Notion is about being the best place for you to collaborate and do your work, and how does that narrative change if the way that we work changes?

Yeah. You told me you were a fan of the Agent Lab thesis, and this is—

I show that thesis to so many candidates. I have it as my Chrome autofill at this point. It’s one of my most visited—

Is this the “Here’s why you should work at Notion and not OpenAI”—

I think it’s like, “Here’s what’s different about it.”

Yeah.

Sara Ma

And here’s why it’s not just a wrapper. I actually think more and more people understand it’s not just a wrapper.

By the way, in the beginning, parts of what we build are wrappers on functionality that works well.

Of course.

But that’s not really the most—I would say that’s not the product that drives revenue, and that’s not necessarily always what users need.

Notion is the AWS wrapper, but the wrapper is very beautiful and very well polished.

The analogy that I’ve been coming back to is Datadog and AWS.

Yeah.

Sara Ma

Datadog could not exist without cloud storage. That is fundamental. That works. AWS has a CloudWatch product, but Datadog is an expert on understanding how people want observability on the products they launch, and we're experts in understanding how people want to collaborate. That's really where our expertise lies—

Totally.

Regardless of the tools that we use.

I'm curious how you think about implicit versus explicit expertise. I feel like Datadog is half and half—implicit and explicit. They understand across markets and industries what engineering teams usually look for. With Notion, it's almost like more of the expertise is at the edge because, as a platform, you're so horizontal that the end user is not really the same.

The end user is always an engineering lead or kind of an SRE-related person. With Notion, it can be anything. So I'm curious how you put that expertise into a product, versus, obviously, AWS cannot build Notion. That doesn't quite work in this case, but—

It's a little differently shaped. I think a classic vertical SaaS, like Datadog, is kind of like that. They understand their individual customer very deeply. It's kind of a narrow slice.

Notion has always been super horizontal, and our task has always been to balance these two somewhat opposing forces: 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 how we decompose what they want into nice primitives that are really nice to use and will get us as much bang for the buck as possible, and then maintain the whole system and make it all look super clean and nice to use.

Sara Ma

We still have user journeys. We still focus on core—I actually think the failure of our team is when we focus too much on what tools are cool tools. I actually think that's when we have the least velocity, because you still need some sort of focus on a user journey.

For instance, we'll all sit down every Friday and look at the P99 of the most token-exhaustive custom-agent transcript and just look at why it didn't do well and cut a bunch of tasks. We still focus on, “This should work.” Email triaging should work, right?

Mm-hmm.

Similarly, when we were talking before building—chatting before we started filming—about how I can do PDF export, that's functionality that merits maybe building a tool that has access to a computer sandbox and a file system and the ability to write code. But it's because we're thinking about the fact that our users, to do their daily work, need to export PDFs, not because we're thinking, “A computer tool could be cool. Let's just see what happens.”

Mm-hmm.

We have to focus on some user journeys; otherwise, we just don't have enough strategy to prioritize.

I think there are a lot of really strong opinions that you've had. Do you have a Tao of Sara Sachs? How do you run your team? I feel like you've accumulated all these strong opinions. Obviously, part of this is your Token Town thing.

4. The Low Ego Culture

Sara Ma

I think the Tao of working with Sara Sachs is that it depends who you ask. I think it depends if you're on my team, a partner, or a vendor.

Yeah. There are other people who want to run their teams the way that you're running these things.

Sara Ma

Yeah, I understand.

But then also, similarly, Simon, when you did the custom agents demo, you had, “We've been using custom agents, and here's the super-long list of everything that we do. No human's ever read it.” That's what you said.

Sara Ma

Mm-hmm. Yeah. So I think for me, something that I learned very quickly and became very comfortable with was that my job was not to be the ideas person or the technical expert. My job was to make it so that everybody understood the objective, had a resource to help prioritize what they should work on, and had an avenue to prioritize what they thought was important.

I think that's true with all leadership, but especially on the AI team. Almost all of our best ideas come from prototypes from people who have a cool idea because they saw a user problem, and it's a huge disservice if all of those ideas have to pass the sniff test of what me and a product partner, or Simon and Ivan, decided was the direction, right? A lot of what we're doing is leaning into capabilities.

I think that's the first thing: I don't really view the role of engineering leadership as hierarchical, nor has it ever been. But especially now, we're very willing to change direction based on the proof being in the pudding.

Yeah.

Sara Ma

I think we have rebuilt our harness 3 or 4 times. When you do that, the second role of engineering leadership is that you need to build a team that's comfortable deleting its own code, is very low-ego, is driven by what's best for the company, and doesn't write design docs because they think it's their promotion packet.

That's a culture that Notion had long before I joined. Our willingness to swarm on different problems and redo things that we've built before because something has changed—there's a lot of friction that can happen at companies when you do that, and it doesn't happen at Notion.

Because it doesn't happen when new people join, they don't want to be the ones saying, “We shouldn't do this. I wrote that code.” So then you create a culture that everyone adopts, and that culture comes directly, I think, from Simon and Ivan, because they're very open-minded.

Anything that you'd add?

I'm not a manager like Sara is. A lot of my role is really to try to think a little bit ahead, make sure that we're building on the right capabilities, and then do the prototyping stuff.

It's really critical to always just be starting again. Okay, there's this new thing. What does this mean? What if we just rethought everything and rewrote everything? I'm basically just doing that in a loop every 6 months.

Yeah. Do you believe in internal hackathons for this stuff?

Sara Ma

I think there's two different versions. One is that we just have a solid bench of senior engineers who come and go through what we call the Simon vortex, productionizing what we've built, right? When you're in the Simon vortex, the velocity is super high, the direction changes daily, and it's meant to be the equivalent of a skunkworks lab.

We don't need to do hackathons for that. We need to have senior engineers that we trust to come in and out of those projects. For instance, management boundaries are really loose. You report to him, but you work for her right now. That's something that, when we hire managers, it's important they don't care about because we tend to form org structures after the fact.

Yeah, don't be too territorial.

Yeah.

Sara Ma

We form org structures after we ship things, not before, just historically. The second thing is we do have company-wide hackathons. Actually, we just had demo day for the hackathon we had last week this morning.

That's more for people who aren't directly working on the project to feel like they have time to pause and learn how to make themselves more productive, or how they would use Notion Custom Agents to build something. Part of the hackathon was actually encouraging everyone across the company to build their own agentic tool loop, coding from scratch and following a blog post on how to do it, I think, because we want—

Shawn Wang

Is that the Compound Engineering one that—

Yeah. We want everyone to use Claude Code in the company, or whatever coding agent they please, and understand that fundamental concept. So we set aside a day and a half where all leadership encouraged everyone on their teams across the company to do it.

We have hackathons like that. Facetiously, everything we build is a little bit like a hackathon until it graduates, puts on big-boy pants, and has a product ops rollout later, with an assigned data scientist and stuff like that. Ultimately—

Security review, enterprise stuff.

Sara Ma

Actually, security review is one of the things that we bring in first because it just slows us down way more and causes a lot of tension, and we build a better product if they're involved early. That's probably the first person to get involved in something.

That's the right PR-approved answer.

Sara Ma

No, no, but it's not just PR-approved. It's like—

It's real. It's actually real. I'm just saying—

Sara Ma

It's scar tissue.

Shawn Wang

Yeah.

Because I also worked at Robinhood for a number of years, compliance and things like that are a little bit more familiar. You learn the hard way when it doesn't come naturally.

Ivan Zhao

Yeah, I think the hackathon is really important for uplifting the general population, but if that's the only way you can build new things, you're toast. It has to be the daily processes of building these new things, and it has to be about—I think, in the AI era, a lot more leverage accumulates to the most curious and excited people.

We're all about just activating that energy. If someone's prototyping something on the weekend that they're excited about and it's important, that should be the main thing that we're doing.

Yeah.

It's not a hackathon that we schedule once a quarter. It's just a daily process.

It's part of the culture, yeah.

Sara Ma

That's how we shipped image generation in Notion. It was always this thing that would be nice to have, but it wasn't really clear how that aligned with product priorities, and it would be a lot of work. We had someone on the database collections team, Jimmy, who was like, “I really want to do image generation for cover photos and inside Notion.” And we were like, “If you want to build it, do it. Please. We encourage you.”

We gave him all the resources for working directly with Gemini, being able to track the token usage, and working through our endpoints. We gave him eval support, everything, and then it became a full project.

Yeah.

Sara Sachs

That's why you can't have ego as a leader. That's how we work.

What's the size of the team today, both engineering and overall?

Sara Ma

I manage the team that we'll call core AI capabilities and infrastructure. That's about 50 people. But then we have AI partner teams that do packaging, so how it shows up in the corner chat versus custom agents versus meeting notes. That's another 30 or 40 people.

And then every team that has a product surface at Notion that a user can interface with owns the tool that the agent interfaces with. The editor team—the team that did CRDT for offline mode—is the same team—

Mm-hmm.

Sara Sachs

—that handles how 2 agents edit competing blocks. It's the same problem. The team that built the underlying SQL engine is the same team that owns how the agent asks it to run a SQL query, and does it performantly.

In that regard, anyone working on product engineering is tasked with making things work for customers who are humans and agents. Because over time, a majority of our traffic will be coming from agents using our interface, not humans. Our objective is to make it so that the whole product organization is building for agents.

How has it changed internally? The activation bar is lowered a lot. Anybody can create a prototype very easily, especially if you're in an existing codebase. Have you raised the bar on what type of prototype people need to bring forward?

The bar is lowered in many ways. One thing our team built that is really cool is that our design team made a whole separate GitHub repository called the Design Playground. It's basically a bunch of helper components for quickly throwing together UIs, and it's become quite sophisticated. It has the agent in there, and that's pretty fun.

Pretty much, they don't do mocks. They just make—

Right.

—full prototypes. They give you a URL, and they're like, “Okay, so we have to make the real production version of that.” And for engineers, a prototype looks like just making it a feature flag that actually works. That's the bar.

Sara Ma

Something to understand that's really unique about Notion—and one of the reasons I joined, we're super lucky—is that no one uses Notion in their job as much as the people who work at Notion.

Of course.

Mm-hmm.

Sara Ma

So I think there are very few companies like that, maybe if you worked on Chrome, I guess. But everything that we ship internally first gets a lot of really quick feedback. Sometimes our dev instance is totally borked, and you have to change a bunch of flags to get things done, and that's everyone.

People who do IT ticketing, supply chain procurement, recruiting—everyone is using the same instance of Notion, with a lot of flags on for these prototypes people build. Brian Levin, one of the designers on our team, evangelized this concept of demos over memos—

Ooh.

Megan Risdal

—which has been very good for building demos, and I think it's put a lot of pressure on us to have really strong product conviction.

Because if anything can be demoed, you really need a strong filter to make sure that if you're doing X amount of work, you're focusing on one tower, not just building a really flat hill. That's actually where I think there has to be more conviction from our PMs and designers. The company really has to have conviction about what journey we're going on.

But overall, I feel like it works pretty well. People—almost all the engineers—have good enough taste to realize whether a prototype actually makes sense in the product. It's not that common that I would see a prototype and think, “Oh, this makes no sense.” People are doing reasonable things, and then it's just a matter of which things we build first, and often just figuring out how to turn them on and off.

In our experimental chat UI, there are probably 100 checkboxes—

Megan Risdal

Guilty.

—different things you can turn on and off.

Sara Ma

Okay, so that is true, Simon. But being the person who manages the evals team, there is a level of intensity that it adds to the platform team.

If we're going to do image generation in Notion, it affects the way that we do attachments and the way that our LLM completion—Cortex—talks and expects tokens back. Now it's getting images back, so there's a lot of platform work that we need to solidify a little bit.

Sometimes it'll be in development for a couple of weeks before it makes it to production, just because we still have to make it robust, make it HIPAA-compliant and ZDR-compliant, figure out the right contracting with the vendor, whatever it is. And we need to evaluate it because we want the team to still maintain what they build.

That's the one thing: if we have a bunch of prototypes, it can't just be a small group of people that then maintain everything in prototypes. So we've invested a lot in evals and model behavior understanding teams. We call it agent development velocity.

Your development velocity in building agents can be faster if we invest in that platform. We have a whole organization dedicated to agent platform velocity, so that you can build your own eval and then maintain it once you ship it.

Shawn Wang

Does every team maintain its own eval?

Sara Ma

We maintain the eval framework. Every team owns its own evals, and a lot of them we've integrated to opt into CI, or we run them nightly. We have a custom agent that triggers a team to look at the major failures.

It's really critical because if we have all these different services, a lot of them are on the same agent harness, so it's easier to maintain. It's just packaging of different agent harnesses. But for new functionality in the agent, let's say they deprecate Sonnet 4 or whatever it is and we need to auto-update it—

Shawn Wang

Have they already?

Sara Ma

I don't know.

Shawn Wang

That's so—okay.

Megan Risdal

Yeah.

Shawn Wang

Yeah, it wasn't that long ago.

I think it was just 3.5.

Sara Ma

3.5 is deprecated.

I think it's 3.5.

Sara Ma

3.7 just got deprecated.

Shawn Wang

I think it's 5.2 or—

Sara Ma

No, it's not 5.2 that's deprecated yet.

No, 5.1, 5.0, yeah.

Megan Risdal

Yeah.

Shawn Wang

Yeah, yeah.

Sara Ma

5.4 is 40% more expensive than 5.2, so if they deprecated 5.2, you would hear from me about that one.

Shawn Wang

Cold after that.

Sara Ma

But that's another conversation to have.

I have a cheeky evals question for you.

Megan Risdal

Yeah.

Shawn Wang

Have you noticed any silent degradation from any of the major model providers?

Megan Risdal

Silent degradation?

Shawn Wang

During the workday—

Megan Risdal

No.

We definitely notice flakiness. We've definitely noticed, particularly for some providers, that things are slower during working hours.

Shawn Wang

But that's a latency argument—

Megan Risdal

Yeah.

Shawn Wang

—not a quality argument.

Megan Risdal

No. I think the quality difference that's interesting is that, even though companies say they're selling the same model through different vendors, it's really about quantization.

Shawn Wang

Yes.

Megan Risdal

Companies that say they're selling the same model through different vendors—whether it be through first-party or Bedrock, Azure, et cetera—we do see different quality sometimes.

Shawn Wang

Yes.

Megan Risdal

And that's not necessarily what's advertised.

Shawn Wang

Yeah, Kitterie[?] went so far as to ship an eval across all the providers, and it was very obvious who was secretly quantizing. It was very embarrassing.

Megan Risdal

Yeah, but that's why we hire subprocessors to figure that out for us. We just want to understand where it's regressing or where it's optimized, and sometimes we're okay with regressions that optimize latency if they're the appropriate regressions.

Our job is to make sure we have the evals to understand the changes that are important to us. Even when we're partnering with labs on prereleases of models, they'll send us multiple snapshots. This is less about quantization and more about regressions.

They have shipped models that were not the snapshots that we wanted, and they have changed the snapshots that they shipped based on the feedback that we give because our—

Feedback tends to be more enterprise-work-focused and not coding-agent-focused. Those can definitely be bummers. We know that this wasn't the version you wanted, but we'll help you make it work. We always make it work, but that definitely happens.

Shawn Wang

Yeah.

Do you have failing evals that you're just hoping—

Megan Risdal

Oh.

—that will eventually succeed when a good model comes out?

Megan Risdal

Yeah. So I think I could talk about this for 60 minutes, so I will limit myself. I think it's a real issue when people say “evals” and it's just like, “That's quality.” That's like saying “testing.” It's not just unit tests.

Shawn Wang

Right.

Megan Risdal

We have the equivalent of unit tests and regression tests. Those live in CI, and they have to pass a certain percentage within some stochastic error rate. Then, as you're building a product, we have evals that aren't passing right now, and this is launch quality. So we have a report card, and we need to be at 80% or 90% on these categories across all of these user journeys to launch.

Then we have what we call frontier or headroom evals, where we actively want to be at a 30% pass rate. That's actually been an effort that we took in partnership with Anthropic and OpenAI over the past 2 or 3 months, because we hit a point where our evals were saturated, and we weren't able to really give insightful feedback other than that it wasn't worse. Not only is that not helpful for our partners, it's not helpful for us to understand where the stream is going, going back to that analogy.

So we spend a lot of time thinking about what Notion's Last Exam looks like, right? Not just Humanity's Last Exam.

Shawn Wang

Ooh, neat.

Megan Risdal

Notion's Last Exam.

Shawn Wang

Mm-hmm.

Megan Risdal

There are a lot of dreams about what that would look like. I know we've talked a lot about benchmarking SWCs, but Notion's Last Exam is a big thing inside the company, and we have people staffed full-time on it exclusively.

Shawn Wang

Mm-hmm.

Megan Risdal

We have a data scientist, a model behavior engineer, and a full-time evals engineer just dedicated to the evals that we pass 30% of the time.

Shawn Wang

Which you're hiring for—MBEs?

Megan Risdal

I am hiring.

Shawn Wang

What is an MBE?

Megan Risdal

A model behavior engineer.

Shawn Wang

Oh.

Megan Risdal

Model behavior engineers started with the title “data specialist” before I joined, when they were working with Simon on Google Sheets. Simon just needed someone to look through Google Sheets and say, “Yes, no, this looks bad, this looks good.” So we hired people with diverse linguistics backgrounds. We had a linguistics PhD dropout and a Stanford comparative literature new grad.

They're amazing, and they formed a new function, basically. Over time, we've built a whole team with a manager who's now reinventing what that role is with coding agents. They used to be manually inspecting code. Now they're primarily building agents that can write evals for themselves or LLM judges.

There's a really funny picture—I can send you the picture—of Simon, about a year and a half ago, teaching them how to use GitHub. They were at the whiteboard, and it was like, “Okay, I think we'd be so much faster if our data specialists learned how to use GitHub and learned how to commit these things into code.” That was then, and now I think coding has been a lot more accessible.

But moving forward, it's this mix of data science, test PM, and prompt engineer, because there's craft in understanding even what models can and can't do. How do we define that headroom? How do we define what a good journey is? Is this model better or not? Why is this failing? There's some qualitative work, but then there's also a lot of instinct and taste to it, and that's not necessarily software engineering.

Mm-hmm.

Sara Ma

We have a very firm conviction, and we've had it for a number of years now, that it's its own career path. We have always welcomed the misfits, so to speak. 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.

Fergal Reid

Yeah, this is something that I've been pretty excited about recently. We made an effort to treat the eval system as an agent harness. If you think about it, you should be able to have an agent, end to end, download a dataset, run an eval, iterate on a failure, debug, and then implement a fix.

Ultimately, you should be able to drive the full end-to-end process with a human observing the outer system. So, yeah, we went pretty hard on that. That's worked extremely well so far. It's basically just turning it into a coding-agent problem.

Your coding agent, or just—

No, just—

—whatever harness—

Any coding agent.

Codex, Claude Code.

Yeah, yeah. It should be totally general. I think it would be a mistake to fix it on any particular coding agent. At the end of the day, it's just CLI tools.

Sara Ma

It's the same way that you would have a coding agent write the unit test. You should have a coding agent write the eval.

Fergal Reid

Yeah.

Nate Parrott

But there's a lot of supervision in that still. We just don't believe that supervision has to come from software engineers, because a lot of it is UX research and whatever. These are the people who also triage failures and tell us where we should be investing next.

Yeah. I'm going to go ahead and ask a spicy question. Is there a day when there are no software engineers at Notion?

Sara Ma

What does it mean to be a software engineer?

Exactly.

5. The Software Engineer Evolves

I think the way things are going is that we're on some continuum. If you look back 3 years ago, humans were typing all the code. Then we had autocomplete, so you're typing a little less of the code. Then we had agents filling lines, and now we're getting into agents doing longer-range tasks where they can debug and implement a fix, verify it works, and get your PR even merged and deployed.

I think we're 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, merging PRs. What's going off the rails? What do I need to approve? Is there a learning or memory mechanism that works?

It's a hard engineering problem. There's a lot to do there. I think we're just moving up the stack.

Sara Ma

The same transition that machine learning engineers have made. I haven't looked at a PR curve in a while.

Yeah, you used to do this stuff, and now autoresearch can do it.

Right. I think it depends on what you define as a software engineer.

Yes. That's changing for sure.

I think every software engineer at Notion this summer went through this shift. One of our engineering leads at the company called it 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. I think that is a transition out of being a software engineer. But—

Yeah.

Yeah. There's a critical difference from being a manager, which is that it is actually very deeply technical. Humans are very fuzzy, and you can't treat a team of humans like a rigorous system where PRs flow through and can be in a blocked status. Then what happens when they're blocked? With a set of agents, you actually can do that.

I think there's actually a lot of interesting technical rigor that goes into that. It's a technical design problem, ultimately.

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

Yeah, I think we're trying a lot of different things. Ultimately, you want to design a system that requires as little human intervention as possible while still maintaining the invariants that you care about. We're exploring a lot of different ideas there. I think I can talk about a few things that are important there.

One thing I think is really important is having some kind of specification layer. You can just commit Markdown files. That works pretty well, but—

It's nice to be Notion, man. I'm just saying, the natural home for specs is Notion.

Yeah. It can be a database of pages. It needs to be something that is human-readable and viewable, and I think that's pretty key. Another really key component is the self-verification loop.

Yes.

Fergal Reid

You need really good testing layers, basically, and that's a really deep problem, but we're beginning that. Then there's the workflow of what happens when there's a bug. How does it flow into the system? Is it a sub-agent working on it? How does it make a PR? How does that get reviewed and merged? There's the flow of the process.

Yeah, cool. One thing we didn't work out before you guys came in was this demo, or this—

Agents.

—agent demo.

So every time we do an episode, we try the product, right? I don't think there's ever been an episode that I haven't tried.

Try is a big word. Since day 1, Latent Space has been on Notion, but this is the new thing. Yes.

6. Custom Agents In The Wild

So this is for Kernel Labs, which is the space we're in. Next week we're opening applications for tenants. So there's a web form. Let me... We have this form Done here.

We have this form done here. Before, the workflow would be that I get an email, then I look at the person and ask, “Should I spend time talking to this person?” Then I respond, they respond back, and so I built this. The name came up on its own. How does it come up with its own name?

That’s a pretty apt name. It’s just a random name generator.

Oh, okay.

Yeah.

That’s funny.

The fact that it picked that is hilarious. I’m pretty sure it’s just deterministic.

Sara Ma

Resilient Collector. I think I’ve never looked at the code for that. I’ve never second-guessed it. I think it’s like a Mad Libs situation.

Yeah, it’s totally deterministic.

Oh.

I thought it was great.

Yes.

Sara Ma

Yeah.

Although, if you use the AI to set itself up, it can update its own name.

Okay.

Sara Ma

How did you create it?

I did, yeah. I’ll say, “Just check my inbox for applications for a coworking space. Keep me in the loop, please.”

Oh, okay.

So it created a database for me, which I have here. I guess a database is like a Notion table because everything is Notion. Whenever an email comes in, it just creates a new row for the person, and then it uses web search to enrich the profile. It searches the web and says, “This is who this person is. This is when they say they want to move in,” and updates everything else.

It’s not AGI, but to me, I don’t want to do this work, so it feels great. It took me maybe 15 minutes to set up the whole thing, and I really like that. Most of the information should live here. It’s not like some other tool asking me to bring my stuff there. I would’ve probably already created a Notion thing.

Sara Ma

Most of our biggest use cases and gains are from that extra layer of human involvement in the process to make it end-to-end. One of our biggest use cases is bug triaging. If someone posts something in Slack, can you just have a custom agent that lives there, has its own routing constitution for what team this belongs to, creates a task in your task database, and then posts in that Slack channel?

That’s 1 of the first things that we built internally, I think, and it’s completely changed the way that Notion functions as a company. Most things don’t fall through the cracks. We don’t know what we don’t know. But it’s not replacing people; it’s replacing processes.

Yeah. I’m curious how you think about the composability of these things. The other one I was working on is a lease filler. Whenever somebody signs up as a tenant, it builds the lease for them. There should probably be some agent, like an office manager agent, that can handle the request, make the lease, and then give them Verkada access to the office and all of that. How do you think about that future?

Yeah. There are 2 ways you can compose. One way is by using the data primitives. You could have 1 agent writing to the database, and there’s another agent watching the database. That’s 1 way they can coordinate. It’s a little bit more decoupled and works really well.

Or you can couple them. I think it’s actually not released yet. We’re releasing it next week. In the settings for an agent, you can give it access to invoke any other agent.

Mm.

Nate Parrott

So you can have them just talk directly.

Was there a limit on the number of recursions?

Probably.

You can just get an infinite loop that way.

Sara Ma

I think it’s limited. There is actually a number somewhere, I believe.

Someone’s gonna screw it up.

You should just try it and see.

Everything’s gonna be paperclips.

Oh, yeah. But that’s really useful. I helped someone internally the other day. They had built over 30 custom agents for our go-to-market team, doing all kinds of different things, like researching, filling in information about a customer, or triaging customer feedback. Literally over 30 of them.

He even made a database of all the agents. Then he said, “Okay, and now I’m getting over 70 notifications per day, with the agents blocked on various things.” I was like, “Oh, okay, cool. The obvious thing to do there is to make a manager agent.”

Akshay Kothari

Yeah.

That’s gonna be another abstraction layer in between your 30 agents. We set it up with a manager agent, and then it has access to invoke all the other agents. It’s watching and observing them, and it just creates a layer of abstraction. Instead of 70 notifications per day, it’s like 5, and then the manager agent can help debug and fix any problems with the agents.

Is this a concept of the inbox or something? Basically, you’re saying that they can message each other.

Boris Power

Yeah.

Sara Ma

Well, it uses a system of record—

Shawn Wang

Or just the notification?

Akshay Kothari

—which is Notion. So—

Yeah, we didn’t make any special concepts at all.

Shawn Wang

They’re integrated into Notion notifications that I would’ve gotten.

Sara Ma

They can just write a task to a database that the other agent is tasked to listen to, or they can actually call a webhook to the agent. They can just @ the agent.

Shawn Wang

Okay.

This is something that we’re still working on.

Shawn Wang

Yeah.

Boris Power

Generally, the way we do these things is you first make it possible in a sort of janky way. The way I set them up is that we created a new database that was for issues the custom agents were experiencing. Then we gave them all access to file an issue, and the manager has access to read the issues. That worked pretty well.

Essentially, we gave it its own internal issue tracker just for the agents. If that becomes a concept that seems useful generally, maybe we’ll think about how to package it in. But generally, we try to keep it to composing the primitives if we can.

Another example of this is that we have no built-in memory concept. Memory is just pages and databases. If you want to give it memory, just give it a page and give it edit access to that page.

Shawn Wang

And a human can edit it, and the agent can edit it.

Boris Power

Yeah. That pattern works extremely well. Depending on the use case, you can have it be just a page, or it could be an entire database. You can have subpages. It’s pretty endless what you can do with it.

Shawn Wang

So when I was setting this up, I connected my inbox, and it was like, “Do you want to use Gmail or Notion Mail?” I’m like, “I don’t want to use either. I just want you to do it.” I’m curious how you think about Notion Mail, Notion Calendar, and all of these UI and UX interfaces.

Boris Power

Oof.

Shawn Wang

Full-stack Notion.

Boris Power

Yeah.

Shawn Wang

When you have the agents abstracting them away from you in a way, how do you spend the product calories, so to speak?

Yeah. I think it’s pretty important that you don’t have to use Notion Mail to get access to the mail capability, so we can just connect to Gmail or whatever you want to use. We’re thinking of the mail service as being really great to the extent that it’s really agent-built. Maybe the mail app is just a prepackaged agent that helps you automate your inbox.

Shawn Wang

The auto-labeling is great.

Sara Ma

When we integrate with Gmail, for instance, we have a series of tools available via MCP or the Gmail API. When we integrate with Notion Mail, we have the Notion Mail engineering team to build us the exact right tools that optimize latency, performance, and quality. They own that quality. There are product leads there who are directly thinking about the user problems that happen in mail.

It tends to be that when we build integrations and connections, we build natively first and then think about extending them generally, just because it’s also easier to build natively first. That tends to be how we phase things out.

7. MCP Versus CLIs

Shawn Wang

Talking about integrations, you prompted me, so I gotta ask: MCP, CLI, what’s going on? What’s the opinion?

Yeah. I think I’m definitely bullish and excited about CLIs.

Akshay Kothari

Yeah.

Boris Power

I think there are a few really cool things about CLIs. One really cool thing is that they’re in the terminal environment, so they get a bunch of extra power. For example, I can paginate and cursor through long outputs, and it has progressive disclosure inherently. You don’t see all the tools at once. You just see the CLI wrapper, and you can use the help commands and read files.

And then I think the most important thing that's super cool is that it's also inherently bootstrapped. So if there's an issue, the agent can debug and fix itself within the same environment that it uses the tool.

Shawn Wang

Hmm.

Boris Power

Right? I think I saw a tweet this morning where someone said, “My agent didn't have a browser, so I asked it to make its own browser tool. Within 100 lines of code, it gave itself a little browser, wrapping the Chromium API.” That's pretty incredible. And then if there was a bug, it would just immediately try to fix it.

On the other hand, if you use the Chrome DevTools MCP, I've had this issue where sometimes the transport gets messed up. If it gets messed up, the agent has no way to fix itself. It no longer has a browser; it's now broken. I think that's pretty fundamental.

But I would say a lot of the bad things about it can be fixed. So I think the progressive disclosure can be fixed with the right harness. It obviously doesn't make sense to show all the tools all the time. That's not really inherent to the MCP protocol; it's just how you wrap it and use it.

Shawn Wang

There are many poorly implemented MCPs because we didn't know better.

Boris Power

Yeah, I mean, it was just early.

Shawn Wang

Yeah.

Boris Power

The obvious thing to start with is to just show all the tools, and it's okay: now we have 100 tools—

Shawn Wang

Yeah, yeah.

Boris Power

—and the tool calling actually works, so let's—

Shawn Wang

The victim of your success.

Boris Power

—give it a way to filter and search the tools.

Shawn Wang

Yeah.

Boris Power

I would say, 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 a narrow, lightweight agent. I think there are definitely a lot of use cases where you don't want a full coding agent with a compute runtime, and also you want it to be more tightly permissioned.

MCP inherently has a really strong permission model: all you can do is call the tools. A CLI is a little bit murkier. It can access the API token. Are you properly re-encrypting the token so it can—

Shawn Wang

Mm-hmm.

Boris Power

—exfiltrate it? It introduces a lot of new issues which are real and hard to solve, and MCP is just the dumb, simple thing that works, and it is pretty good.

Akshay Kothari

I'll add 2 more perspectives—not from whether it's working well for Notion, but from how Notion commits to both platforms. Notion is dedicated to being the best system of record for where people do their enterprise work, so we will always support our MCP insofar as other people are using MCPs, right? Regardless of our perspective, we've put a lot of effort into our MCP, and we have a fantastic team that we're building to do more there.

And the second thing I'll say: we all think a lot, but lately I've been thinking a lot about making sure there's a value alignment in pricing with capability.

Literally our next question.

Sara Ma

Needing a language model to execute deterministic tasks feels wasteful, and requiring a language model to interface with third-party providers seems wasteful for tasks that don't require it. And particularly because our custom agents are using usage-based pricing, we think of pricing as the barrier to entry for use of our product, and we're quite committed to making sure that it's not wasteful.

Not just because it's a bad deal for our customers, but it's also bad business. We want as many buyers. There's an elasticity of demand. And so if we can have our agents properly execute code that calls on a CLI deterministically, it's a 1-time cost, right? Versus constantly having a language model integrate with an MCP over and over and paying those repeated token fees.

And if it's happening outside the cache window, then you're paying for it over and over, and it's just unnecessary and less deterministic when it doesn't have to be.

Shawn Wang

Yeah, the open-endedness. I think the main thing is, if I go write code to just call an API, I would never use an MCP. But then you need an MCP sometimes when you know what to call but you don't want it to restart, versus—I think the... It built a browser from scratch.

It's great when you're doing it on your own, but if your customers were having your AI write a browser from scratch every time and you had to pay the token cost of that—

Akshay Kothari

Yeah.

Shawn Wang

—you'd be like, “No, the Chrome DevTools MCP is actually pretty great. Just use that.” I'm curious, how do you make that decision? Should it be just a straight API call, very narrow? Should it be an MCP? Should it be super open-ended?

Akshay Kothari

Do you mean for when we ship Notion capabilities, or when we add capabilities to Notion AI?

Shawn Wang

Yeah, or—I mean, you might have a capability where the only way to do it is with an open-ended agent, like an agent with a coding sandbox.

Akshay Kothari

Yeah, in Notion AI, though, not explicitly—

Shawn Wang

Yeah, yeah.

Akshay Kothari

—because we also ship an MCP—

Shawn Wang

Yeah, yeah.

Akshay Kothari

—and an API.

Shawn Wang

Internally.

Akshay Kothari

Okay.

Shawn Wang

Is there ever a discussion where we're not going to ship it because we're not able to tie it down, or are you happy to just—

Akshay Kothari

No, there are a lot of things where we choose not to use MCP because we want to add more high-touch quality. I think search and agentic find is the largest instance of that, where we have Slack, Linear, and Jira search in Notion that is not necessarily using the search MCP functionality provided by those companies. That's because it's quite critical, we think, to how our agent trajectories work: for us to have a little bit more control on the functionality of the search journey.

And so it usually comes from quality. And there's a long tail of things, and that's why we built an MCP client—or an MCP server, excuse me—so that people can connect to whatever they want. There is that long tail, right?

But for search particularly, I would say that's the primary entry point, but there are other connections as well. It's a little bit of secret sauce about when we are okay with MCP functionality and user-driven auth and when we actually want to carry a lot more ourselves.

I think that there's not really a conflict here. There's just different layers of the stack and different abstractions. If we were to map it out, you've got MCPs. They give you a way to gain access to tools. It's an open protocol, so you can easily get a long tail of many things.

So if you open up our tool settings—

Oh.

Guest

I saw the trigger. So that's something that MCP can't do. So if you scroll down—yeah, the Tools and access section—you're going to add a connection, yeah. MCP is a really great way to gain access to tools.

Mm-hmm.

Guest

It works really well. But you just looked at the trigger UI, for example. There's no trigger protocol, and so—

Mm.

Guest

—those we've got to build ourselves. And then there are some integrations where we use MCP. So, for example, I think the Linear and GitHub integrations—

Guest 2

Mm-hmm.

Guest

—they use MCP, but Slack, email, and calendar are actually ones they built in-house, and we spent a lot of time really fine-tuning all the tools to make them actually really good and also building out the triggers.

So it's just different layers of the stack. Some things make sense sometimes, and then we just have to harness the right tool at the right time. I don't think there's an inherent, strong conflict between these things.

Do you have a canonical representation of these tools internally, where you've wrapped these things together—the MCP plus the custom-built?

Yeah, yeah. We have internal abstractions for what is a tool, what is an agent, and what is a completion call. Yeah.

Sara Ma

We even have internal abstractions for what is a chat archetype, whether it's from Teams or Slack.

Mm-hmm. Yeah. It's like the only way—

What is a task?

—to build with AI because everything's moving so quickly. You would have to abstract it so that you can swap things out.

Guest

Yeah. Yeah, there's always a dance. We've probably rebuilt our framework, like I said, 5 different times. It's always a dance of, okay, how does this new thing work? What should the abstraction be? What is OpenAI giving us? What is Anthropic giving us? We kind of wrap over it.

I think we've been pretty successful with that. It's just a matter of staying nimble—

Yeah.

Guest

—and making sure that you always have the simplest, dumbest abstraction you can—

Yeah.

Guest

—that maps over different things, yeah. So we have a tool integration abstraction, for example, and then MCP is a type of integration.

Yeah.

Guest

That's one of them.

This might be a big ask, but I'm going to try, which is, you've said multiple times you rebuilt it a few times, like 5 times. I don't know if that's the right number. Is there a brief history of what each rebuild was doing? And, yeah, I know it—

Guest

I can try to do that. Yeah, there's interesting—

This is the thing you need to RAG over.

Sara Ma

Archaeology.

Write the highlights. Wow.

The first version that we started building was in late 2022. Oh my gosh, there have been many versions, actually. The first version we built was actually a coding agent.

Yeah.

Guest

So we were like, oh, instead of building tools, let's make everything be JavaScript, and then we'll just give it JavaScript APIs, and it will just write code, and that's how it speaks to the tools.

But at the time, it just sucked at writing code. It wasn't that good. So then we moved to more of a tool-calling abstraction. But tool calling didn't exist yet, so we created this whole XML representation. A big learning in that version was that we were catering way too much to what made sense for Notion and Notion's data model versus what the model wants.

Mm.

As an example, we created this whole XML format that could losslessly map to Notion blocks, and the transformation between them was super easy to do. Then we created these mutation operations to edit pages. But it sucked because the model didn't know the XML format.

And you had to prompt it in—

Yeah, you had to prompt it in, and the trigger was just more inconvenient. So we were like, “Okay, it has to be Markdown.” The models know Markdown. We did a whole project around basically creating a Notion-flavored Markdown, where the whole goal was that it had to be just simple Markdown at the core. Then we could add some enhancements, and it didn't have to be a full lossless conversion.

That was a big one. Then we did a whole similar learning in the database layer, so, to querying a database. In the Notion API, the way you query a database is through a crazy JSON format. It's limiting, but it maps nicely to how we represent things internally. We scrapped all that and said, “Okay, let's just make it SQLite.” Everything's a SQLite database. You can query it just like a SQLite query, and the models are super good at that.

Give the models what they want.

That was another one. Give the models what they want. I would say that was a big learning: just really be savvy and careful, thinking about what the model wants in terms of its environment, and cater around that. Try so hard not to expose it to any unnecessary complexity about your system.

Notion's underlying database is PostgreSQL, right?

Yeah.

So I don't know if there's any mismatch there.

That one was a fortuitous thing because we already had a big project going. When you query a Notion database, it's actually querying this cluster of SQLite databases. That's something we'd already been working on even before the agents came around.

You guys had a fantastic blog post about it.

Yeah.

It's actually really good database engineering knowledge to have that from you guys because where else would we get it?

Yeah. It's a crazy engineering problem when you want to have millions and billions of tiny databases, or where some of them are tiny but some of them are very large, and you want everything to be very fast.

Yeah, and also not that hierarchical sometimes.

Yeah.

So somewhat of a graph. I do like that history because I think that shows the evolution that you guys went through and the work that went into it.

Guest

He just joined you a year and a half ago.

Oh, okay, okay.

Yeah.

Guest

If you're curious—

I can do that as well.

Guest

—we can keep going.

These models are weird.

Guest

I'm just saying that's really—

That's another one. Yeah.

Guest

I mean—

Let me think—

Guest

No, because there was tool calling, and then there was research mode, which wasn't fully agentic tool calling. Then we moved—

So no few-shot prompts ever? Okay, maybe not ever, but—

Guest

I don't know—never, but—

Yeah, that kind of went away. It's an interesting thing.

Right?

Yeah.

These just instruction-follow really well.

I would say there's been a general arc where you gradually strip away everything, and it looks more AGI. It started out as a one-shot, one prompt. There were few-shot examples, and it became, “Okay, actually, let's give it tools, but it'll still have few-shot examples.” Then it became, “Actually, let's just give it a whole bunch of tools.”

One big shift I've been working on recently, that's about to ship, is what happens when you have a lot of tools.

Yeah.

So then—

Tool search.

Yeah, so progressive disclosure becomes really important. We hit a bottleneck where our agent worked really well, but it became pretty hard to add new tools, and we became worried about breaking the model.

Guest

No, I just heard that saying hello was thousands and thousands of tokens.

Shawn Wang

I can see you're the efficiency person here.

Guest

Yeah.

It was too many tokens, but also it's a quality issue because it meant that any engineer could introduce a new tool for some niche feature, and it would nerf the overall model by causing it to call the tool too much and stuff like that. So we had an effort to implement progressive disclosure in a nice way. That's a big shift.

Guest

You said earlier that everyone says reasoning models were the big shift. What's more there? When we went away from few-shot prompting entirely to tool definitions and describing the goal of the tool—goal-driven, basically moving from a DAG to a true system with feedback—that's when we could distribute tool ownership to the teams much better.

Because when it was all few-shot, everyone was truly editing one string, and things would compete. There were all these papers about, “Oh, not all context is created equal. The higher up it is in your examples, the more the model listens.” We were trying really hard to fight against the order and the selection of the few-shot examples, and that really had to be a center of excellence. It didn't scale with the number of people or with the needs the company had.

It was really just 5 or 6 people who were allowed to even touch that—or had to approve it, rather—in our codebase. Now, with the right eval setup, we can distribute things so that everyone owns their tool and their tool definition. Sometimes we have crazy things where we write 2 tools that have the same title and the agent crashes, and stuff like that. So there are issues.

Actually, believe it or not, Anthropic couldn't take it. Sonnet couldn't handle 2 tools with the same name, and OpenAI's GPT-5.2 was like, “I can figure this out.” So—

Mm.

That was an interesting one that we learned by accident through a SEV. But—

I mean, then the underlying representation is a dict, right?

Right.

Clearly, that's a safety key name.

Yeah, exactly. But that was a big shift for the company in velocity. Not immediate, because the AI team—the center-of-excellence team that owned that one file of few-shot prompts—had to become a platform team overnight, and that wasn't natural.

Yeah.

But I would say that in terms of the velocity of how we contribute to the agent, beyond coding tools obviously being a big velocity lever, being able to distribute tools and not have to all collaborate on one very select string of system prompt is truly, I would say, the biggest lever in how we've scaled.

We're just fighting to keep the prompt as short as possible now, and then—

Yeah.

Yeah. It's the latest version of the agent. It's not in custom agents yet, but it will be next week or the week after. There's now over 100 tools just for all the crazy Notion stuff, so we're able to really go deep in—

Would you list those tools publicly? Is this IP?

No, it's totally public.

Okay.

You can ask the—

You can find them. Just ask.

Well, you can just ask the agent—

Yeah.

—and it will tell you.

Yeah.

And we're going to post a benchmark—

You're going to post a benchmark?

We don't think our system prompt is our secret sauce.

Yeah.

Mm-hmm.

Great.

We don't try to hide the tools—

Yeah.

—at all. I think it's kind of important, actually, as an operator—

Yeah. As a power user, I want to be like, “Oh, it can do this? Great.”

Yeah, yeah. One phrase we say internally a lot is, “Teach to the top of the class.”

Really?

The custom agent's like a power tool. We try to make it as easy as possible to set up, but we want it to be pretty deep and sophisticated. I think a huge part of that is that the operator needs to be able to interrogate the way the system works. A big part of that is: What are the tools? How do they work? How should I prompt it to use the tools in the right way?

I'd actually say we don't try to make it as easy as possible to use, because the more we do that, the more we abstract away that interpretability that Simon's talking about, which basically nerfs the model or nerfs the agent—

Yeah, yeah.

from being super capable. So a huge turning point, I would say—I can think about the week and a half that we all came together on this as we were building custom agents—was aligning on the fact that we're not trying to build for everyone here. We're not trying to build a model or user experience that anyone can figure out how to use. The more we do that, the more we diminish its capabilities. Everyone aligned on that in a couple of Slack messages, which actually made us all work faster again because we were more focused on who we were building for.

What does the meta-prompt generator look like? I looked in the—

Mm.

—the system prompt that it generates. For example, it uses emojis. That's not an obvious thing to be doing.

Kevin Hou

Wait, did you just ask it, “What’s your system prompt?” Oh, this is how to generate prompts—the prompts to generate prompts.

We got it set up, Kevin.

Kevin Hou

Yeah.

Kevin Hou

So this is actually just the agent.

Yeah.

Kevin Hou

One thing I really like about custom agents is that the agent can set itself up. We not only gave it access to use the tools it has access to—send your emails or whatever—but it also has more tools to set itself up and debug itself. So when you ask it to write a system prompt, your agent itself is doing that.

So this is just the model preference.

You're not really injecting—

Kevin Hou

—and then—

—into the model too much.

We say what makes a good custom agent—

Kevin Hou

Yeah.

—and things like that. Then it's really nice because if it fails, you can ask it, “Why did it fail?” and then say, “Okay, update your instructions so it doesn't fail again.” Obviously, we should build a self-healing product.

Yeah.

That's next on our roadmap. But actually, it creates a nice system.

Kevin Hou

Yeah. We essentially give it a development guide: “Here's how to make a custom agent. Here's how to help the user test it end to end, to help them gain confidence that it works,” and stuff like that.

Yeah, the fixing thing worked. It wasn't automatic, but I mis-set something up, and then there was—

Fix button.

—a fix button, and then it just—

Yeah.

Kevin Hou

Yeah, yeah.

Fix this agent.

Kevin Hou

If I may say a little bit more, it's actually an interesting sort of permission problem. The thing about custom agents is that, by default, they have no permission to do anything. You have to explicitly grant them all their permissions, and that's what lets you trust that they can work in the background. You can know, “Oh, it can read my email but not send an email. Okay, I can trust that.”

Yeah.

Kevin Hou

If you let it fix itself, you're breaking the permission there.

Yeah.

Kevin Hou

It's not allowed to edit its own permissions. But in the current product, you can click a button to fix it. Now you're entering an admin mode where you're in a synchronous chat, and you can see what it's doing.

Yeah.

And it confirms before it changes.

Yeah. The thing I really like that most people don't do is that the editing chat is the same thing as the using chat. You can message the agent to both edit it and use it, whereas a lot of other products are like—

Kevin Hou

I think that's really key. I think—

I think a lot of designers will be so happy you said that—

Kevin Hou

Yeah.

—because we spent… We called this Flippy.

Yeah. What is this? What do you mean?

Kevin Hou

Yeah, so if you close that and open Settings, you can see—yeah. We call it Flippy because we started with the settings as the main page, and then you could test the agent. The AGI-pilled way to think about it is, “Oh, it's just the agent. Everything's the agent.”

Right.

Kevin Hou

It can set itself up, it can test itself, and it can run the workflow that you want it to run. So we flipped it. The main view is the chat, and the settings are more like a side panel previewing the changes that it's making, so you can introspect on them. You can also make changes manually if you'd like. But we want to design the experience from the get-go so you never have to touch any of the settings manually. You can just talk to it.

The inside baseball is that how this works was probably the launch-blocking part of this—

Yeah.

—especially because we had a lot of early adopters who were used to the old way. That's the benefit of adopting in public, but changing how people think about setting up custom agents when they already had this flow was difficult in and of itself.

Kevin Hou

That was really fun because we ended up painfully delaying the launch by—

A month.

Kevin Hou

—a few weeks. Yeah, definitely like a month or so. But the whole team was super enthusiastic about it because it was just so much better. It was like, “Oh yeah, obviously you have the chat with it—

Right, yeah.

Kevin Hou

—to set itself up,” and everyone was super bullish on that. So it was painful for a second, but then everyone was like—

And, going back to organization design—which I probably care about more than Simon—the people who built this are 3 engineers from 3 different teams because we were like, “We need to launch this, and we need to fix this.”

Right.

And then we've just built a company where we just put people on it, and no one complains. The manager doesn't complain, and we were able to unblock and just ship it.

Yeah, but being in a failure chat and asking it to just fix itself is amazing, versus having to copy this and put it in the settings chat. “Do it.”

Kevin Hou

Yeah. We're trying to explore a trade-off here. We want to be a business- and enterprise-safe agent where you can delegate something and trust that it's going to work. But we also want to get some of that bootstrapping power that—

Mm.

Kevin Hou

—that you feel when you're coding and it's making a browser for itself, right? There's something there. I think that's really important. So we're trying to navigate that trade-off and try to get you both.

Now it's free.

Yeah.

It's amazing.

Kevin Hou

Thank you.

I'm worried about when I have to start paying. How do you think about pricing? You have Notion credits as payment for this, which is separate from the usual tokens that the model generates. How do you design value-based pricing based on the task and things like that?

8. Pricing The Agent Future

The credits and payment structure are associated with token usage. The reason that we had to make it not just the throughput of tokens is that it's not always priced that way. Our fine-tuned open-source models are served on GPUs.

Right.

Web search is priced differently. If we were to host sandboxes, those would be priced differently. We had to think of an abstraction above tokens, and it's also not just tokens. It's the token model and serving-tier trade-off, right?

Mm.

We can have priority-tier processing. We can have asynchronous processing. The cache rate could be different depending on who uses it and when, right? We wanted, from the get-go, to commit to making sure that customers were getting a fair deal—not necessarily that we were making a ton of money off of it, but that customers were paying for what was reasonable. That's the fundamental of where we started, and we're also selling enterprise SaaS.

So if we sell credit packs, then you get discounts. If you're an enterprise and you buy a certain amount of credit packs, you get discounts and things like that. It also just helped the sales motion work a little bit easier. So that's the answer on the abstraction of credits to dollars. Was the question how we decide how to price it, or—

Yeah. I think not all tokens are made equal, but—

Yeah.

—we obviously get charged mostly the same. You can ask Codex to create a dumb tool for you. I created one for our StarCraft II LAN for people to find the game. But then people use it to build features in billion-dollar companies, and the token price is the same.

Yeah.

For you, I can ask this to update my favorite recipes doc, and it'll do it, but I could ask it to respond to an email from an investor, and the value is very different. You could charge more, but you're not necessarily doing it, so I'm curious if there was any discussion.

I think that's not where the market is right now, number one. The second reason that we're not doing that is that it ended up being complicated to figure out what was complicated or not. At first, we were like, “Let's just charge on agent runs,” and you know what? You went through all the different versions that ultimately just brought you back to a lot of complexity that mapped directly to token throughput. So it's also just simpler.

It's quite difficult to build those pricing systems, and I actually think that one of the biggest reasons we wanted to have usage-based pricing for this capability is that we've had our core agent for a while with a model picker. There were certain models or certain functionality for which we had margins to maintain, and if we wanted to ship this functionality, you…

Madhu Muthukumar

We couldn't afford it. It would bankrupt the company. For instance, the database autofill feature will soon be agentic. That will be associated with usage-based pricing because if every single autofill action was an agent running on Opus on every single database cell, it would be billions of dollars, right?

And so we had to find a way for the customers that wanted to do more and wanted to give us their money and pay more to find an outlet for them to do it, so that we didn't have to apply it to the lower end of the curve. Also, not all knowledge work is equal. There are different points. A lot of the agent workflows here really saturate model capabilities. You don't need—

Mm.

Madhu Muthukumar

A complicated model for it. Charging based on token usage, we couldn't just decide for you whether you wanted your email client to be dumb or not.

Right.

Madhu Muthukumar

We want you to decide. If you want to have Opus auto-triage all of your emails, we will actually give you nudges in the product to rethink whether that's the right choice. Because not every user—

Understands.

Madhu Muthukumar

You'd be surprised. In user interviews, people will be like, “Oh, I didn't know that.” So now we actually have a little hover that tells you if it's expensive or not. Yeah. It's also slower. The interesting thing is that people don't care about speed in custom agents, and so—

Mm.

Madhu Muthukumar

The incentive of Haiku being faster—people don't care when it's asynchronous. We want to provide only the extra benefit that people want, and the best way to do that is to incentivize them because it's their own money.

It must be confusing for people who aren't familiar. It's like, why is there no 5.3? You open this thing—

Madhu Muthukumar

On—

—and it's, “Is there something missing on my menu?”

It's not their fault. Not their fault.

Yeah, I think it's—

Yeah.

Madhu Muthukumar

I think it's—

That's just the world we live in now.

Yeah. It just randomly jumps 0.2. It's like Claude had that.

Madhu Muthukumar

I think 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.

Shawn Wang

Auto.

Madhu Muthukumar

Nice. A lot of our job is actually figuring out Auto, because it's—

Shawn Wang

This is—

Madhu Muthukumar

Like—

Shawn Wang

—the agent lab. Every agent lab has an Auto, because that's the job.

Madhu Muthukumar

Exactly. Because if you think about it, like I said, I come from Robinhood. You could spend a lot of time keeping up with the markets, or you could have it auto-investing, right? You can have an index fund, or you can have—

Shawn Wang

Robo-advisors of—

Madhu Muthukumar

A robo-advisor.

Shawn Wang

—of landmaking [?].

Madhu Muthukumar

And so, at a certain point, we also can be robo-advisors. We have a lot of people figuring out what model is best for the right task. Right now, we're not using Auto as a margin maker. We're just using it to reduce stress. It's not Opus, that's for sure.

Shawn Wang

Yeah.

Madhu Muthukumar

The majority of the tasks people are doing aren't Opus-level intelligence.

The thing I would say is that, unlike a lab, we aren't fully incentivized just for you to use as many tokens as possible. We're actually really interested in giving you the right tool for the job. A lot of the time, the right tool for the job is actually just writing code and not even using an agent at all. That's something that we're—

Shawn Wang

Mm.

—investing in a lot. Imagine your agent can actually automate itself out of a job. We would love if that were true.

Madhu Muthukumar

I feel very strongly about this because I don't necessarily feel like those are the SKUs that frontier labs give you. I feel like they're just getting more and more capable and more and more expensive, which is fantastic for the use cases where people want to do really complicated things on Notion.

What's difficult is that market that I think right now is no man's land—the place where reasoning models were 6 months ago, that the Nanos, Haikus, et cetera, haven't caught up to. Because now we're just paying more for those extra capabilities that we didn't necessarily need, and so are our customers. Labs aren't necessarily incentivized right now, with how few players there are, to be meeting the market everywhere. They just need to be the cheapest. They don't need to be at the value that the customer wants.

Shawn Wang

Mm.

Madhu Muthukumar

If no one is cheaper than them, then they're the cheapest, and that's good enough. And so we're doing a lot to make sure that we have the right optionality to switch between models and also invest in open source.

The open-source models are actually getting to be where reasoning models were 3 or 4 months ago, and that's what's filling that gap right now. So you'll see we offer MiniMax, and we're collaborating a lot with different open-source labs to think about Humanity's Last Exam and how they can do better on these types of tasks, so that we can offer them for that intelligence-to-price-to-latency trade-off.

Because in that triangle of intelligence, price, and latency, excuse me, users get to choose where they are. But right now, the whole triangle isn't filled with models, right?

Shawn Wang

Yeah.

Madhu Muthukumar

And the more that different models fill—

Shawn Wang

Everyone's clustered on capability.

Madhu Muthukumar

—that triangle. Everyone's clustered in capability. Haiku's not that much cheaper. No one's really in the middle. People really tend to cluster around 2: this is really capable, and it's really fast, but it's really expensive, or whatever. We just want to make sure that triangle is filled. We want to offer the models that fill it, and we want to guide users to understand when they need it—

Shawn Wang

Yeah.

Madhu Muthukumar

—and which one.

Shawn Wang

All I'm hearing is that someday you're going to train your model. You have lots of tokens.

Madhu Muthukumar

I don't know if—what do you mean by “train your model?”

Shawn Wang

Train your own model.

Madhu Muthukumar

I don't know if we have the money to train a foundation—

You go raise it. You can raise it. You—

Madhu Muthukumar

You can raise it. That's your job, Simon. No, I don't think that needs to be our core competency.

Shawn Wang

This is usually the thought process that leads to, “No one else is doing it. We'll take a crack.”

I feel like, to the extent that we do anything like training, the area I'm actually most excited about is less of one big model for all the users, but, as it becomes more possible to make specific fine-tuning that's really aware of your context of your company, the people that work at your company, and what's going on. I think that's pretty interesting, because if you had a model that really knows your company, I think that would be a huge quality uplift.

Madhu Muthukumar

We actually have some enterprise vendors that ask about this, along with bring-your-own-key. If I have a model that really understands my enterprise, that's what we're training for, for all these reasons. These tend to be quite large institutions thinking about how to let people bring their own models, but those models have to function with—

Shawn Wang

Right.

Madhu Muthukumar

—understanding how to call our tools. That's where, again, having a more public system prompt is beneficial to Notion, right? We want all models to plug into Notion as well as they can.

That being said, of course, there are certain aspects of Notion where we do fine-tune and do reinforcement fine-tuning on our own capabilities, but that's not necessarily trained on user data. You don't need that much data in the first place, and that's where, when we have a data scientist and a model behavior engineer who really understand where the capability gap is, that's when we invest there.

I personally burned a lot of time trying to train models.

It's tempting, right?

It's so tempting.

Ivan Zhao

Training is—

It's so cool.

We're retraining every day.

I was doing a crazy amount. I was doing a lot of different things.

Ivan Zhao

I was the budget person that—

Timeouts.

Ivan Zhao

I showed up and heard that was happening.

I have a funny thing: the arc looped back on itself. When I was doing tons of training stuff, it took a long time to do any kind of training run, and you ended up operating 24/7 around the clock. It became very important that, before you went to sleep, all the experiments were started.

As I stopped training, that kind of went away. But now the coding agents have totally brought this back. So now every night before I go to bed, I'm like, “Okay, did I start enough agents to get them done?” I get them done.

I just—

Yeah, it's an interesting arc.

This reminds me of how you have to try polyphasic sleep so you can wake up every 2 or 3—

I saw that. I have not gone there yet, but my goal these days is just to have the agents running before I go to bed, and I'm confident that they won't be done by the time I wake up.

Really? 8 hours.

Ivan Zhao

I won't say which coding frontier lab, but there is a point where he had outlived the thread length and context length—

that the coding agent provided, and you DMed them, being like, “Hey, I need more.” And our account rep DMed me directly, and they were like, “Is Simon trying to prove string theory? What is he doing?”

Yeah.

Yeah. I had a single coding agent thread going for, I think, 17 days—pretty much continuously.

Don’t they just compress?

Yeah, yeah. So it was actually just a bug. It was a harness bug. It had done compaction probably 100 times—

Yeah.

Overnight.

The other thing that reminded me about fine-tuning, which I think you and I have aligned on, is that our tools change really frequently. Right now, we spend a lot of time rethinking and building tools for capability, and fine-tuning a model to understand your tool.

We don’t have legal expertise or coding expertise, so if we were to fine-tune a model, it would either be expertise about the enterprise—and we have ZDR, no-data-retention offerings for those enterprises, so we’d have to really rethink how we structure that if an enterprise wanted to opt into it—or it would be fine-tuning for better capability in navigating our tools.

That doesn’t match the velocity with which we create new tools. It would actually really slow us down to have a model fine-tuned on our tools, because we’d have to retrain it and cut a new model every time we did that, and that’s not how we’re set up right now. I guess we could fine-tune a model to search for tools. It’s just—the amount of time it takes to do that, ship it, and have the right system, you’re basically making a bet against a frontier capability not serving that in the time it takes you to build it.

That timeline hasn’t happened for us yet. It hasn’t been a bit.

Mm-hmm.

I think it’s just the wrong trade-off. You want—yeah, we literally change our tools every single day, and if we notice an issue, we’ll fix the problem. I think a good way to think about it—I think it’s pretty fruitful—is don’t focus too much on training. I would think of that as an implementation detail.

What’s the outer loop, right? If the outer loop is that you have a model and then some harness or system where it’s interacting with the system, that needs to work. And if there’s a problem, the way to solve the problem isn’t necessarily to train a model. It’s, “Oh, maybe there’s just a bug in one of the tools,” and actually, 99% of the time, it’s a bug in one of the tools.

Right.

And so just fix the bug. The outer-loop thing that’s really fruitful to think about is how you can improve your velocity and robustness: making really good tools, making a good harness, and verifying it works.

The one place that we do invest more in model training now, necessarily, though, is actually retrieval. We’re at a point right now in our business and enterprise AI-enabled plans where the search load and search traffic—a majority of it—is coming from agents, not humans.

For every query that’s hitting our Elasticsearch or our vector indices, they’re not coming from humans, and the queries are structured differently. What’s returned has a different requirement. Positional ranking matters less, but top-K retrieval mode matters more.

Isn’t top-K a form of position?

Of course it is, but when you’re training on click-through rate, it’s really—

Yeah, it matters much less.

Number 1 through number 6—

Yeah.

—is very different—

Yeah.

—than it needs to be in the top 100.

The slope is just—

Yeah.

Higher.

It’s a different optimization function—

Yeah. Flatter, yeah.

—for the retrieval model. Similarly, what snippet you include matters more or less, so we are rethinking a lot of that functionality to work with how agents like to write queries and how they want to receive information.

Yeah.

So we are doing another kind of reinvestment into rethinking not only search—how agents search versus how humans search—but we’re also investing in indexing different things now. How do you index the stuff generated for Notion Agent? It breaks our block model entirely, where all blocks are nested in each other. Same with meeting notes.

So we’re hiring ranking engineers and model-training engineers, but it’s primarily on ranking.

Yeah. Does ranking map to RecSys for you—recommendation systems?

Yeah. Yes.

Okay. I’m saying this a bit: I’m trying to promote RecSys more in general because it’s weirdly unpopular.

I don’t know why.

Yeah.

But the other thing is that I was just talking about this with a peer: how important ranking is versus being able to do parallel exhaustive queries. So we’re also—

They’re both important.

They’re both important, but they’re both two tools to the same user outcome or the same agent outcome.

Uh-huh.

Right? And that’s something that we’re also rethinking a lot. We just did an experiment on Notion ranking at this point. For Notion retrieval, vector embeddings are less and less—

Oh, did you see that? Notion just switched to night mode. It waited so long, it became dark mode.

We’re working the night shift for you, right?

Looks pretty. Not seeing any bugs. I worked on this parallel-search thing where, if you fan out to 8 different queries, right—

Yes.

—and so you actually need to use the model to work on query diversity so that you get—

Right.

—maximum search space.

The people who are working on ranking and retrieval are the same people working on query generation. It’s all one journey.

Yeah.

We call it agentic find, and we’re actually realizing, for instance, that it’s less about a selection. We don’t spend a lot of time trying to optimize what vector embedding we use anymore. That was a period of time, but that’s just not the right level of optimization.

Remember that? Yeah. Okay, we’ve gone long. I have to talk about Notion meeting minutes, and then we can call it there. You just have a lot of comments. I don’t know where you want to start. Is it the audio side? Is it the summarization?

Oh, meeting notes?

Yeah. What makes it work? No, just anything interesting technically. I think you had some bookmarked points. I always call these checkmarks along the way. When a guest says something that they want to return to later, I just checkmark it. I’m like, “Okay, we’ll get back to it.”

9. Meeting Notes Become Data Capture

Yeah.

Sara Ma

Meeting notes was one of those things where, at first, we were nervous that we’d have to teach people a different way to work, and we were nervous there’d be a lot of user friction. I think one of the reasons why—I mean, they’re one of our biggest growth levers. I think they’re one of the strongest, in terms of virality of adoption and retention. And so we’ve invested more and more as we did that.

I think what’s really powerful about it is, again, Notion is the system of record of where and how you work. The way that I use meeting notes is that every 1-on-1 and meeting I have is in meeting notes. When I do my performance review for myself, my self-review, I say, “Primarily look at all my conversations with my manager and write up what I did this year.” Right? Because if I didn’t talk about it in my 1-on-1 with my manager, it probably—

Mm-hmm.

—wasn’t relevant for my performance review. So it also just adds a ton of signal on prioritization that’s really helpful for a good system of record, and that’s really helpful for our agent.

Mm.

It’s also caused a lot of scaling for search and for the agent, and it’s just an explosion of content when you have transcripts like that. How we do compaction—a lot of that was triggered by meeting notes passed into context, things like that. So it’s been a good impetus for us to think about longer-form content when you think of it as a priority primitive. But it’s been one of the most powerful signals for our agent because it—

Unsurprising, right?

Right. And so—

Like, you’re capturing a whole new thing.

It’s like our own data. We want users to create their own data flywheel, right? And it’s—

It serves me to prefer Notion and put all my stuff there because it has my other stuff.

Totally.

Yeah.

The way that our teams run right now is that there’s a custom agent that does a preread before stand-up. It looks through all of Slack and GitHub and creates a summary and a meeting note, and it says, “Everyone, do this preread.” Then we just press play.

We have the meeting. We talk through the preread. We talk about what needs to happen next, and then we have a custom agent integrated with our calendar and triggers that then files tasks for tomorrow or today based on what we spoke about and sends off Slack messages that we decided in the meeting needed to be follow-ups.

Our meetings are hands-off-keyboard, and we’re focused on the root of the problem, not the bookkeeping around the problem.

One thing that the meeting-notes team added recently that has been blowing my mind is that they made it so that, when it makes the summary, it will actually @-mention the people who were referenced. Oof.

In it, so I now get notifications whenever someone talks about me in a meeting.

Guest 2

Yeah.

Guest

What if there are 2 Simons?

Sara Ma

No, wait. It’s powered by the agent, so it’s doing agentic work. When it’s doing the summarization, it’s figuring out who Simon is—

The most probable Simon, yeah.

Guest 2

We also have a people-to-people similarity cache and stuff like that in the attendance database.

Yeah.

Guest 2

There are ways—

We also generate a profile for each person and use that. Of course, it can get it wrong, but the goal is for it not to get it wrong.

Sara Ma

Meeting Notes is just the agent primitive packaged on top of a transcription primitive, and then there’s a vertical team. It’s probably one of the only teams at Notion that’s completely a vertical team around quality and product, including UX design, because it’s still a tiger team, with a fantastic manager, Zach, who joined recently from Embra.

Zach Tatar, yeah.

Guest 2

Yeah.

I chatted with him when he was talking about when he was working at Embra.

Sara Ma

Yeah. So he’s managing that team now and thinking about it as data capture. That’s what Meeting Notes is: data capture.

Get all the content.

Guest 2

It’s kind of reframing where Meeting Notes are valuable as a data-capture problem. The summarization used to not be agentic.

Yeah.

Guest 2

Now it is, because it does all the things like figuring out who the right Simon is. One day, you can have a custom agent directly integrated in it that knows what task database the meeting is referring to and, as you’re having the meeting, perhaps updates the task and things like that. There’s a lot of that experience of where we do our work in meetings that we want to invest in making more seamless.

Yeah. OpenAI’s doing hardware. Would you ever ship one of these? Yeah, probably not.

This is Meeting Notes in person. Yeah, yeah.

Sara Ma

I think it’s a mechanism, and one of those needs to work really well with Notion. We would partner with whoever is building one of those.

Yeah.

Guest 2

There are some wild companies doing really cool things that come to our partnerships team. I like to sit in on the demos of wearables. I always like to sit in on the demos because I think they’re pretty cool.

Guest

Oh, okay.

Guest 2

And all of them want to make sure—not just with Notion, but, as you can imagine, with the ones that talk to you—that you’re able to do search and build context. So if you’re entering a conference, you can look at your CRM and do things like that, and you can utilize the Notion agent to do that. So we are in the very beginnings of those partnerships. I think what’s unique about that particular technology is that it goes against what I talked about with custom agents right now: the simpler it is, the harder it is to have advanced controls over its capabilities. And so that would be a great investment for data capture, but not necessarily for our agentic workflows.

It’s a little bit of a different slice of the problem. That’s going to be deeply personal. Your company isn’t going to force you to wear a wristband. I think—I don’t know.

Sara Ma

It’s good to hear that from you.

Yeah. It will, yeah. The CEO’s going to force everyone to wear a wristband. Look, the slice of the problem that we care about is: can the company have all the context of what everyone said at every single meeting and then use that to derive value for themselves?

Sara Ma

That kind of reminds me: I remember once you very strongly reminded me that our job is not to 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.

Yeah. So basically, you’re saying everyone else can just pipe to you, and it’s fine, right? Yeah, that’s a reasonable thing. All I will say is that there are people walking around with Notion tattoos on them. They’ll wear Notion anything, so I don’t know, do a limited run. Notion tattoos.

Sara Ma

We have such understated swag that the idea—our swag has so few Notion logos on it—that the idea that people have Notion tattoos is pretty antithetical to our design principles. That’s pretty funny.

Yeah. Hmm.

Guest 2

Do you have one?

No, definitely not. I do not have a Notion tattoo. I’ve seen them, yeah. Cool. Thank you so much. This is such a great deep dive. Actually, the chemistry between you two is amazing. I can’t believe—

Guest 2

We work together a lot. Different jobs, work closely.

Yeah.

Guest 2

Thank you.

Guest

That’s it. Yeah. Thank you. Thank you.

Guest 2

Thank you.

Thanks for joining.