从笔记应用到 AI 工作空间:Simon Last 专访
- Notion 的 AI 战略已从写作工具推进到自主工作。2022年接入 GPT-4 后,Notion 在2到3个月内于2023年2月推出 AI Writer;工作空间问答于2023年10月进入 GA;个人代理则在去年秋天、约8月或9月上线,此前 Notion 已尝试打造代理3到4次。对投资者而言,关键不是押注某个模型,而是迭代速度:Notion 大约每6个月就会重写一次 AI harness。
- 有用的企业级代理,底层工艺在于检索质量,而不是工作空间是否整齐。Embedding 让层级结构没那么重要,因为 AI 只需找到正确片段;但分块大小、处理流程和针对不同来源的调优仍然困难。针对 Sarah 所说原生产品尚未完美解决这一问题,Simon 表示,大多数公司“索引做得相当差”:Slack 和 Google Drive 不可能共用一套检索策略。
- 编码代理带来的远不只是团队缩编,而是人才差距急剧拉大。Notion 仍偏好小型 tiger team,但 Simon 认为,熟练使用工具的开发者如今可能成为“100倍甚至1000倍工程师”:“最低门槛没有变,但最高上限大幅提高了。”代价在运营端:取决于架构、验证、审查和安全部署,代理既能产出大胆且经过充分测试的工作,也可能“全是垃圾”。
- Notion 正从由人操作的软件,转向由人管理并授权自主代理的工作空间。个人代理继承用户权限;自定义代理初始没有任何权限,之后可获准监控 Slack、创建任务、开展研究,或在后台处理报告。Simon 更大的判断是,代码能让代理自行补齐缺失能力:“我把编码代理看作 AGI 的内核。”
- 随着模型能力和经济性持续变化,平台策略刻意保持模型中立。Simon 称 Notion 是“模型界的瑞士”,认为客户应能随时切换模型,因为不同实验室会在不同月份领先。他说,4个中国开源模型已经“相当不错”,而且比前沿模型“便宜得多”;Notion 上周已接入其中1个,并计划提供全部4个。
- 实际工作流已经进入管理者模式,自主权通过“审批—信任”循环逐步获得。Simon 会让 Claude Code 或 Codex 代理通宵运行,曾让1个编码代理连续工作13天,并表示:“我从去年夏天起就没写过代码。”他的邮件代理先通过访谈和日常纠正学习偏好,随后自动归档约95%不需要他处理的邮件——这是他成为“代理经理而不是程序员”的最清晰案例。
1. GPT-4 将双重愿景变成了分阶段交付
- Simon 将信念的起点追溯到2022年在墨西哥举行的一次公司外出活动。当时,GPT-4 的 ChatGPT 原型界面已经能够遵循“相当复杂的指令”,知识储备则“非常、非常深”且覆盖广泛;他和联合创始人 Ivan 因此得出结论:“时机到了”(the time is now),因为“它只会越来越好”。
- 第一款产品是写作助手,可以生成、编辑或改写用户选中的文本。tiger team 在2到3个月后于2023年2月推出 AI Writer,因为这是一项不需要检索的单步任务。与此同时,Notion 也在开发一款通用助手,使其能够在更长周期的工作中操作数据库和文档,但这一版本当时还无法正常工作,距离真正有用也远得多。
- 工作空间问答在测试版之后,于2023年10月进入 GA。它需要实时语义索引、有依据的回答和更强的评测体系,而不只是“把 LLM 插进去”。随后,Notion 又将索引扩展到 Slack、Google Drive 以及更多连接器;Simon 称这套系统是“一段持续多年的旅程”。
2. 检索优势来自持续迭代,而不是整洁的工作空间
- Sarah 指出,原生产品尚未完美解决搜索问题。Simon 说,这会让人追问“我们凭什么做这件事”,随后给出直白答案:大多数公司“索引做得相当差”。他的办法是对查询进行经验测试,并针对每个信息源投入“工艺和心力”,因为 Slack 和 Google Drive 存放的是本质不同的信息。
- Embedding 改变了用户的取舍:只要能检索到正确片段,层级结构就没那么重要。Simon 现在会建议用户:“不用那么在意组织方式……直接扔进去。”Sarah 则区分了这种便利与其隐藏的难点:分块大小、检索阶段和针对不同来源的调优仍然“极其重要”。
- AI 编排层仍然是可替换的一次性工程。Notion 大约“每6个月左右”重写一次;在录制时,一次替换预计将在1到2周内上线,但继任版本已经进入考虑范围。Simon 警告,公司不能在模型能力加速提升时,交付一套架构后就将其冻结。
3. 代理放大工程野心,也放大验证不足的代价
- Simon 将编码分为3个时代:制表式自动补全、插入或重写代码,再到代理。去年4月左右采用 Claude Code 后,端到端的实现、验证和维护成为可能,但前提是工程师重新设计架构和验证闭环。做得好,代理产出的系统可以更有野心、更稳健;“做得不好,就全是垃圾”。
- 团队形态的变化小于个体差异的变化。Notion 仍偏好“小型 tiger team”,但 Simon 说,工具熟练度可能让一个人成为“100倍甚至1000倍工程师”。他的精确表述是:“最低门槛没有变,但最高上限大幅提高了。”
- 因此,组织体感变得“更混乱、更无序”,原型和野心勃勃的 PR 都更多了。设计团队搭建了 Design Playground——一个包含简化版 Notion、UI 基础组件和代理的 Git 仓库——让设计师可以产出并部署高保真原型,而不是静态稿。
- 即便“现在所有 pull request 都由代理编写”,审查仍然是硬性要求。更大、更复杂的 PR 是代价,更好的测试则是收益。Simon 反对单纯的“凭感觉写代码”:人必须定义变更内容、验证方法和安全部署方案,然后再次核对结果。
4. 自定义代理将权限、代码和模型变成平台
- Notion 曾经“3到4次”尝试打造通用代理;早期版本表面上能工作,但并不实用。个人代理最终在去年秋天、约8月或9月上线,几乎可以访问用户在 Notion 中能访问的所有内容,因此能够创建数据库和文档、进行更新、搜索网页并开展研究。
- 录制前一周上线的自定义代理颠倒了这一权限模式:它们初始无法访问任何内容,随后才获得为具体任务授予的权限。一旦获权,代理就可以自主运行,例如监控 Slack 并创建任务,或搜索周报和工作空间。
- Simon 希望先用一个小型“内核”补齐缺失能力,包括构建并部署一项尚未支持的集成。这让编码成为知识工作中的工具:“我把编码代理看作 AGI 的内核。AGI 将是一个编码代理。”代码提供确定性逻辑,也提供连接新数据的路径。
- 面对模型实验室和大型软件平台,Simon 将 Notion 定位为“模型界的瑞士”。客户不应被锁定在单一实验室,因为模型领先地位会不断变化;他说,4个中国开源模型已经“相当不错”,而且比前沿替代方案“便宜得多”。Notion 上周已接入其中1个,并计划在其人机协作工作空间中提供全部4个。
5. 管理代理成为新的思考工具
- Notion 发现了“一个新的客户,那就是代理”。原本冗长的 block JSON “对代理来说糟透了”,因此团队为页面构建了一套增强版 Markdown 方言,并通过 SQLite 暴露数据库。设计过程结合了 token 效率实验,以及基于第一性原理、对模型先验中已有模式的推测。
- Simon 的工作环境是命令行中的 Claude Code 或 Codex。他会在睡前安排足够多的任务,确保代理第二天早上仍在运行;目前最长纪录是连续13天不间断工作。他越来越像一个端到端任务的“外部验证者”:检查结果,并在代理偏离轨道时持续监控。
- 他的邮件代理会读取工作和个人邮件,将偏好记录在可编辑的记忆页面中,并通过访谈和纠正逐步学习。几周后,Simon 取消了审批;代理现在会自动归档他不需要处理的“95%”邮件。另一个代理则将 Slack 上的产品反馈和 bug 分发给对应团队,并在长期运行中学会数百条归档规则。其运行模式是:反复原型、审批、观察,随后授予自主权。
- Notion 通过工作坊和黑客松,帮助非技术团队跨过理解提示词、触发器和代理行为的初始门槛;Simon 说,People 团队成为自定义代理采用率最高的团队之一。最终的重新定义十分明确:在 AI 之前,Notion 的目标是帮助人完成工作;现在,它的目标是帮助人管理完成工作的代理。文档和数据库仍会存在,同时还会出现用于表示和交互代理的新基础组件:100个后台编码代理需要一块看板,“而不是100个聊天线程”。Simon 现在是“代理经理,而不是程序员”。
Welcome, Simon. Thanks for doing this.
Of course. It’s really fun to be here.
Notion is at scale—an amazing platform with lots of users. You did start quite a while ago. I think of Notion as one of the companies that has really raced AI quite aggressively. I was told you first got your hands on GPT-4 at a company offsite in Mexico. Is that true? What’s the origin story of starting to work on this stuff?
That year was 2022. I’d been watching what was going on. In general, I’ve just been super curious about the technology and fascinated to try everything and think about how we can apply it. It wasn’t until I played with GPT-4 that it became really, really real.
When we got access to it, it was sort of a proto-ChatGPT-like interface. My co-founder Ivan and I both got access, and it was immediately clear to both of us—I’d say there were 2 big things. One is that it was pretty smart. It could follow reasonably complicated instructions, write things for you, and edit things.
The second big thing was that the scope of its knowledge was extremely interesting: super, super deep and broad world knowledge. When we played with it, it became instantly clear to both of us: okay, the time is now to start thinking about how to apply this. It’s only going to get better.
We’re talking about Mexico and GPT-4. You guys saw that it was clearly the time. Did you start with a particular vision of what you should obviously be able to do with AI in Notion, or did you start pulling people from different teams or recruiting people and saying, “Let’s experiment”? How did you begin?
I think we immediately had a long-term and a short-term vision. I’ll start with the short-term one. The thing that was immediately obvious was that it could be a writing assistant. It could be in your document: you could select some text and have it rewrite it. You could have it write text for you, maybe look something up, and then give you sources or more information.
That was the thing that we immediately got to work on. We started a tiger team around it, and then we were able to launch it in 2 or 3 months. The long-term vision that we immediately had was that it might be possible to build more of a general assistant.
What if you could just give it all the tools inside Notion that a human would be able to use? It could create its own databases, query and manipulate them, create documents, edit them, and weave all of these things together to do a longer-range task. We immediately started on both. The short-term one we were able to ship very quickly, and the long-term one didn’t really work yet. That took much longer to get working.
Was the first launch of the AI-specific Notion features and products last year?
No, it was February 2023 when we launched.
My timelines are wrong. Are there a few specific learnings or breakthrough moments you think have been interesting since you began releasing this stuff?
It’s been a slog over many years—or over all the years at this point—with many, many learnings. To give you a timeline of the arc of what we shipped, the first thing was our writing system. We called it AI Writer. That was the first thing we launched.
It was easiest to get working because it’s a single-step task: rewriting and editing text. There’s no retrieval aspect. It was just raw access to the model to write text.
The next big thing that we immediately started working on was Q&A: doing a semantic index of the entire workspace and then letting you ask a question, and it can give you an answer grounded in the sources. That was also immediately obvious to us as being super useful, so we started to work on it.
We launched that one in October 2023. We started a beta before then, but our general availability was in October. That was a much bigger effort to get working, obviously. We weren’t just plugging in the LLM. It was actually doing this real-time-updating index. We had to get much more serious about the evals and the quality there as well.
Q&A has been a multi-year journey. Basically, what we did was, as soon as we got the Notion index working, it was obvious that we should index everything else as well. We index Slack and Google Drive, and we’re launching new ones on a regular cadence. Now we have, I would say, a fairly complete index.
Those are very difficult problems that those products natively haven’t solved perfectly yet. I don’t know if that’s an offensive thing to say about other product teams, but it’s not working yet.
It’s kind of true. This is something we talk about a lot because it’s almost like, what right do we even have to do this? But it turns out that most companies are pretty bad at making their indexes. Honestly, it’s kind of baffled us a little bit.
My take after dealing with all of this and working with the teams trying to get it working is that there’s a little bit of AI-pilled savviness that’s pretty important. Most of it is honestly just a bit of craft and attention to detail.
In particular, with this indexing and retrieval stuff, in order to really get it working, you have to be quite empirical and iterative and actually try queries. Each data source is a little bit special. You can’t just apply a one-size-fits-all approach to querying Slack versus querying Google Drive, for example. They’re completely different kinds of information.
We found that there’s just a little bit of craft and love going into it in terms of actually trying a bunch of different queries, using it every day, and constantly iterating, rethinking, and tuning how the retrieval works.
How did you think about the diversity of how people organize their workspaces? Even Notion isn’t used homogeneously, right? I’m probably part of 15 workspaces as an investor. I look at them, and I’m like, “Well, mine’s a mess, and these people are really organized,” and the workflows are reflected in how their Notion works.
Totally. The interesting thing is that with embeddings, it almost doesn’t matter as much anymore. The AI doesn’t really care what the tree structure is. All the AI cares about is that there’s a snippet of text that has the context you need and that it can retrieve it.
We advise people now: don’t worry as much about organization. Just find a way to get it all piped in and throw it in there.
You still make decisions that could change performance quite a bit, like chunking strategy or whatever, right?
Yeah, that’s super important. But that’s sort of transparent to the user and independent of their particular method of organizing things.
It still seems like a difficult technical challenge, given how different the content bases are.
Yeah, I think that took a lot of iteration. Chunk sizing, how retrieval works, and the different steps in the retrieval pipeline—all of that involved a lot of iteration.
Ivan said I should ask you how many times you’ve rebuilt Notion and rebuilt your harnesses.
It’s kind of a running joke, almost. We rewrite our AI harness probably every 6 months or so, and the time to rewrite it has been decreasing because products have been accelerating.
I think this is honestly a really key thing, and something that a lot of companies get wrong: doing one thing and then just sticking with it. You really do have to be keenly aware of what the current state of the model and the technology is, and then design the harness, system, and product deeply around that.
It basically means you have to rewrite it every 6 months. I find it pretty fun. It’s part of the process. You get to restart and rethink it.
We’re working on a new version of our harness that we’re about to release in the next week or 2, and we’re already thinking about the one after that as well.
I think that leads to a set of questions I have for you about how Notion’s engineering, product, and research organization works now that you have the power of coding agents as well. I imagine your willingness to rewrite the harness goes up dramatically: agents are going to help me do it.
That’s extremely true. It’s been really fun to use coding agents. I think the ambition of what I even consider building has gone up a lot.
What do you think has most dramatically changed in how you think about how engineering and product should work at Notion over the last 2 or 3 years?
Woof, yeah. It’s definitely changed multiple times.
I mean, in terms of the coding agents, we went through multiple eras. There was the tab autocomplete era, and then we got into inserting and rewriting some code. But it wasn't really until the agents started working. I would say early last year we started to adopt the agents. I started using Claude Code around April last year, and that was a huge unlock.
The big shift there is that you can really push on getting these agents to implement, verify, and maintain things end to end. But it requires significant thought in terms of how you architect things and what the verification loop is. The upshot is, I think if you do it well, you can be much more ambitious about what you're building and also make it much more robust than you could have done with humans writing it. The flip side is, if you do it badly, it's all slop.
Does that change your lens of what teams should look like at Notion—in terms of size, seniority, or anything like that?
I would say the fundamental effect is that everyone's individual impact in terms of their output can be much higher, and your output increasingly depends on your ability and willingness to use the tools. I think that's the fundamental thing that's happening.
As for how that plays out, I don't think we've seen that much impact on team size, really. We like to work in smallish tiger teams for the most part. If you can make a team small, it's almost always better. That was true before, and I think it's still true—maybe increasingly a little bit, but not that much. The main thing is to really harness the tools.
Do you think something different happens to the median engineering organization versus the 10x engineer, or the engineer who's 10x more willing to use the tools?
I think the gap is bigger. You can be a 100x or 1,000x engineer if you use the tools right now. I think the gap is much bigger. The minimum bar has not changed, but the maximum bar has increased dramatically.
One impact it has had internally, I would say, is that broadly, things feel a little bit messier and more chaotic. But I kind of love that. There are more prototypes—way more prototypes. For example, our design team made an entire Git repository. They call it the Design Playground, and it's essentially a simplified Notion with a bunch of UI primitives.
Okay. Got it.
They've made it really sophisticated. It has an agent in there, and it's pretty cool because it allows all the designers to spin up super-high-fidelity prototypes really quickly. It's no longer pointing at a mock and saying, "How would this look?" They'll give you a URL to a prototype that's been deployed.
That sort of thing is true all the way up and down the stack for all of engineering. It's just a little bit more chaotic, with more stuff happening. All the pull requests are more ambitious.
Do you draw a line somewhere about stuff that's more dangerous to touch or sensitive? Is there a risk of data loss over here, or do you look at it all as fair game?
We still do reviews on all the pull requests. All the pull requests are now written by agents, and they're often larger and more complex. That's the worst part. But the better part is that they're often much better tested, and we can demand much better testing for the things that merit it.
I never produce a pull request that hasn't been fully end-to-end tested anymore. You can get to a pretty high degree of confidence that it works. But it requires more than just vibe coding by saying the thing you want. You're thinking carefully about what the change is you're trying to make, how it can be verified, and how it can be deployed safely, and then enlisting the agent to help you with that process.
When you think about where you said the general assistant doesn't quite exist yet, what do you imagine Notion's agents being able to do over the next year or two that they're still blocked from doing, either by capability or by your harness work?
We struggled for a few years to build an agent. It always sort of worked, but then it wasn't that useful. Largely, it was too early. We tried to build an agent, I would say, three or four times. Then we finally launched it last fall, around August or September.
If you use Notion AI now, it's the full agent that has access to pretty much everything in Notion. That totally works. A lot of the original vision that we had works now, and it's fully shipped.
Last August or September, we shipped our personal agent. Pretty much every user in Notion has an agent, and it has access to all the things that the user has access to. It can create a database for you, update things, create documents, search the web, and do research.
The second big thing that we just launched last week was custom agents. You can create a new custom agent and give it a name. Unlike the personal agent, by default it doesn't have access to anything, so you have to grant it access. But once you do, it can actually run autonomously in the background.
For example, you can give it access to its own database to file tasks, and then attach it to a Slack channel. It will start responding to people on Slack and fulfilling tasks. That's one use case.
Another one is that you could give it access to a database of weekly reports, and then let it search the web or search your workspace. A custom agent represents some work or job—some knowledge-work task that you want to be done autonomously.
One thing I'm really excited about going forward is that we want it to be extremely good at bootstrapping its own capabilities. Basically, from an initial kernel, allowing it to bootstrap itself to do anything. For example, it might build an integration that we don't support yet, deploy it, and then use it.
So you imagine that Notion agents are actually the broader definition of an agent, where writing code is a tool that it has access to?
I think it's pretty key. I think of coding agents as the kernel of AGI. AGI will be a coding agent. Code is just a really, really useful primitive for representing deterministic logic.
The thing that's really exciting about applying it to a knowledge-work agent is that it can bootstrap a capability. If an integration doesn't exist, it can build it. If it needs to connect itself to a new data source, it can do that.
Given that you have Notion at that scale, you're operating in a landscape of productivity and platform players that are at even more scale, right? Many of these will end up with their own agents. Lots of people from the labs and the Microsoft world are trying to integrate other data sources. So you have this cross-attempt to integrate and index. How do you think that plays out? What do you imagine Notion agents are best at, or what do they have the right to go do?
If you look at the landscape, I would say there's the labs, then maybe the software platforms, and then maybe infrastructure.
In terms of the labs, we see ourselves as Switzerland for models. Our customers don't want to be locked into a certain lab's model. They're always releasing new versions, and in any given month, one is better than the other. We want to be a place where you can easily get access to all the best models at any time, and easily switch around.
Do you think open source plays into that as well?
Absolutely. I think the open-source models are actually getting really good. There are four different Chinese models now that are quite good.
Yeah.
We just released one of them in our agent last week, and we're going to do all four for sure. They're actually quite good, and they're way cheaper than the frontier models. So I think there are a lot of use cases where you'd want that, and we want to give people that option.
In terms of the other platforms, we think of our role as taking all the best models that we can, creating really high-quality, state-of-the-art agent implementations where people can easily and conveniently get access to them, and then making a collaborative workspace that's really good for humans and agents to coordinate in.
I think it's something that's very needed in the world, and we're just trying to do it in a really tasteful, well-executed way.
You were describing how you need the index to make the agents good. You give the agents access to the tools that we humans have in Notion. How do you think about the structure of Notion, and where is it useful—or not useful or relevant—for agents? Blocks, databases, and such.
It's all still pretty useful—extremely useful. There's been a challenge: we want to make it really convenient for the agent. I think that's a new thing that didn't exist. In the past, it was convenient for humans, and then we also made APIs convenient for humans writing code to our API. So we essentially have a new customer, which is the agent.
At first, that was definitely a problem. For example, our API uses this crazy JSON format for blocks that, by default, is crazy verbose and horrible for the agent. But we took on that challenge and designed really convenient APIs for the agent. We created a sort of Markdown dialect that looks like normal Markdown, but it's enhanced with all the Notion blocks. The models are really good at it; it works really well. That's how it reads and writes the pages. For databases, we use SQLite, so basically it speaks SQLite, which also works really well. The default thing did not work really well, but we took that on as an engineering challenge, and now we have extremely convenient APIs that agents are naturally good at.
How did you understand or figure out what would make the API better for agents?
That's a good question. I would say it's a combination of just trying things. It's very empirical. We're playing around and noticing, “It's not very good at that. That's way too many tokens. How can we make this smaller?”
Then there's a little bit of first-principles thinking: What are the models being trained on, and what's in their prior? What do they know, and what do we think they would naturally be good at? How does the agent loop work, and what would be the convenient, efficient pattern for accessing these things? Then just a lot of playing around.
I hear user research where the user is actually an agent.
Yeah, you just chat with it. The user's always there. It's ready to talk to you.
Actually, that is wonderful, where you have infinite access to it.
Infinite access to it. You can script and scale the access as well.
I assume you have—actually, I know you do, because you walked in and you were like, “Hey, I need to get access to Wi-Fi. I need power. We can't block the agents while we're doing this.” What do you have running right now? Tell me about your setup.
I'm working on a new prototype, and I have a couple of agents working on that. My setup these days is either Claude Code or Codex. I like the CLI tools. They're super simple and work pretty well. I'm pretty comfortable in the CLI.
You don't need a generated game to use the CLI. It's a very cool idea.
I would say my whole goal these days is essentially to have as many running as possible and to run them all the time. Every night before I go to bed, I'm like, “Okay, let's go, guys.”
Basically, what I have to do is make sure that I've given it enough stuff that by the time I wake up in the morning, it will still not be done. I've maximized that.
That's victory.
Yeah, that's victory. I've done that for the last 5 nights pretty well. My personal record is that I've had a coding agent running for, I think it was, 13 days straight without stopping, just basically working through tasks, well prompted.
I admit to having woken up in the middle of the night at least multiple times this week and just being like, “Are you still going?”
Yeah, I know. It's kind of nerve-wracking. I always check it one last time before I go to bed and really make sure that it's still spinning.
What about the Notion agents? Do you have a workflow there that's core to your daily work?
I use our personal agent all the time, so it has all the context about our company and everything that's going on. For example, last night I was asking it about how the custom agents launch was going and what signals we were getting from it. It was super useful for that.
I have many custom agents that are running. My personal favorite is an email triage agent. It has access to all of my work and personal emails, and it wakes up every day and archives all the stuff I don't need to see. I trained it over time to learn my preferences.
Do you actually label data for it?
It's pretty easy to do this, actually. All you have to do is make the agent, give it access to your email, and make a blank page that's its memory and let it edit that page. Then you say, “Okay, now go and look at my emails and interview me. Ask me which things…”
It will propose things that it thinks it should archive, and you can correct it. It uses that to essentially generate a list of rules about what it thinks is correct or not. For the first couple of days, I was correcting it on things. After a couple of weeks or so, I dropped the approval entirely, and it just automatically archives all the things I don't need to see now.
Wow, that's a lot of trust.
It completely solved my email problems because I don't use email that much for work stuff. It's mostly in Slack. 95% of the personal and work emails that I get, I don't need to see at all, so it's just a waste of time. It completely solved that. Now, whenever I look at my inbox, it's only stuff I need to see.
I've got lots of custom agents running. There's another one that I built that triages customer and internal feedback and bugs. We have a Slack channel where people just post random product feedback and bugs. In the past, it would sometimes get answered, but then sometimes it would get haphazardly ignored because there are so many teams running things.
Its entire job is just to route it to the right place. It uses a similar memory pattern where it learns on the fly where it's supposed to file bugs. Over time, it's built up hundreds of rules that it learned. For example, if there's a bug about the mobile app, it knows to route it to the mobile team and file a task in their database.
Do you look at the generated and updated memory because it's legible to you? Do you look at it and say, “Does that make sense to me?”
I think I did at first, but once you trust that it's working, you kind of ignore it. If it ever breaks, I'll go fix it. It'll break every now and then, but I'll go fix it.
But the benefit of not reading your email is here.
Yeah, you just don't read it. Generally, the pattern I follow is that I build it as a prototype and have it in approval mode, where I'm watching it closely. After it runs a bunch of times, you trust that it's working.
Is there anything you do internally at Notion to make sure nontechnical teams have the intuition for how to build agents or how to express that productivity, too?
It's a great question. We do workshops and hackathons pretty frequently. For example, a month ago, I did a hackathon with the People team and got them started. The People team's been amazing. They're actually one of the highest adopters of custom agents. They do all these workflows in Slack and Notion, manual work like that.
People are super excited to try it and maybe just need a little bit of a push in terms of intuition and getting them started. Honestly, I've been super impressed. I think the concept is intuitive once you get past a little bit of the technical barrier of what a prompt is, what the agent is, how it gets triggered and woken up, and how that even works. Once you get past that, I think it's actually a very human-like interface.
Maybe the biggest barrier is actually just getting people to try it and assuming it's going to work at all.
You and Ivan originally met on the internet, in the Tools for Thought community. It feels like the tools we have for thinking are very different now. Has your core conception of Notion changed over the last few years because of all the AI stuff? What thinking does the tool do for you? What should agents do for you? What do you get to do?
Yeah, it's changed quite a lot. Broadly speaking, before AI, our goal was to create the best tool for humans to directly perform their work. Now the goal is to create the best tool for humans to manage agents to do the work for them.
That's a big shift. That's a pretty big shift.
It's pretty fundamental. But it turns out that you need most of the same primitives. All the primitives that we built are still extremely useful.
It’s more that we needed some new primitives, like representing what an agent is and how to interact with your pages and databases. But you still need the same primitives. You still need a document. It’s an unstructured way to write things, and agents love to write Markdown documents, so it’s still very relevant.
You still need a database. You still need structured data. If you’re working with your swarm of 100 background coding agents, you don’t want to have 100 chat threads. You want a Kanban board. It’s the same as before. You still need the coordination structure.
Makes sense. You still need the coordination structure. What is one thing that, because you’re ahead of this and trying to figure out how to bring Notion and its users along with you, has really changed about how you personally build, even in the last 6 months?
It’s completely changed. I haven’t written code since last summer. I don’t type code anymore.
We went from humans typing all the code to still typing, but using tab completion. Then we started talking to the agent, and it would do little tasks for us, but we were still in the outer loop. Now it’s more like I design an end-to-end task that involves making some change and verifying it end to end. Then I’m the outer verifier, double-checking at the very end that it’s correct and monitoring it if it’s going off the rails.
It’s a complete shift. I’m now the agent manager instead of the coder.
Amazing. Thanks, Simon. This has been a great discussion about how we’re all going to become agent managers, hopefully in Notion.
Cool. Yeah.