CHAPTERS
- 0:05 – 1:41
Mexico offsite: first GPT-4 demo that made AI “real” for Notion
Sarah and Simon set the scene with the story of getting early access to GPT-4 and why it immediately changed Notion’s priorities. Simon explains what stood out: instruction-following capability and unusually broad/deep knowledge, making it obvious the technology would rapidly improve.
- •Early GPT-4 access at a company offsite and the “this is happening now” realization
- •Two core impressions: strong instruction following and broad/deep world knowledge
- •Shift from curiosity/experimentation to committing to product direction
- •Belief that model quality would only accelerate from there
- 1:41 – 2:58
Two-track roadmap: AI writing assistant now, general assistant later
Simon outlines how Notion kicked off AI work with both a short-term and long-term vision. The near-term goal was an in-doc writing assistant that could rewrite and generate text quickly; the long-term goal was a true assistant with access to Notion tools and the ability to complete multi-step tasks.
- •Short-term: “AI Writer” as an in-document writing/rewrite helper
- •Long-term: agent with full tool access (databases, docs, editing, querying)
- •Tiger-team execution to ship quickly while incubating the harder agent vision
- •Why the long-term assistant initially didn’t work and needed more time
- 2:58 – 4:45
Shipping timeline: AI Writer (Feb 2023) to grounded Q&A (Oct 2023)
Simon walks through the arc of what Notion shipped first and why. AI Writer was a simple, single-step task; grounded Q&A required a semantic index of the workspace plus rigorous evals and quality work, making it a much heavier engineering effort.
- •AI Writer launched February 2023 as the first AI feature
- •Q&A required semantic search + grounding in sources; GA in Oct 2023
- •Real-time updating index as a key technical requirement
- •Raising the bar on evaluation and answer quality for retrieval-based features
- 4:45 – 6:03
Semantic indexing & retrieval: why it’s hard and why others underperform
They dig into why high-quality indexing/retrieval remains difficult, even for companies closest to the data. Simon attributes success to ‘AI-savvy’ iteration and craft: testing real queries, tailoring per data source, and tuning pipelines rather than relying on one-size-fits-all approaches.
- •“What right do we have?”—building better search across tools than native products
- •Importance of empirical iteration: run real queries, iterate constantly
- •Data sources differ (Slack vs Drive) and require tailored retrieval tactics
- •Chunk sizing, pipeline stages, and tuning as major performance levers
- 6:03 – 7:17
Organization vs embeddings: why messy workspaces can still work
Sarah raises the diversity of how people structure Notion, and Simon explains why embeddings reduce dependence on a strict hierarchy. Notion increasingly advises users not to over-optimize manual organization, since the model primarily needs the right textual snippets and good chunking/retrieval under the hood.
- •User workspace structures vary wildly; retrieval must handle heterogeneity
- •Embeddings lessen reliance on folder/tree organization
- •Practical guidance: focus on getting information into the system
- •Chunking and retrieval tuning remain critical but are mostly transparent to users
- 7:17 – 8:12
The six-month rewrite: rebuilding the AI harness as models evolve
Simon describes Notion’s habit of rewriting its AI harness roughly every six months. The rationale is that products must be designed around the current state of models and tooling; sticking with a single architecture too long is a common company mistake.
- •Notion rewrites its AI harness ~every six months; cycles are accelerating
- •Harness design must track the fast-moving frontier of models/tech
- •Rewrites enable rethinking product + system assumptions rather than incremental patching
- •Upcoming new harness release and already planning the next iteration
- 8:12 – 9:44
Coding agents change how engineering works: ambition, verification, and “no slop”
The conversation shifts to the impact of coding agents on Notion’s engineering and product workflow. Simon describes the progression from autocomplete to real agents and emphasizes that agents increase ambition and robustness only if paired with strong architecture and verification loops.
- •Multiple eras: autocomplete → rewrite/insert → true coding agents
- •Agents enable end-to-end implementation + maintenance when verification is solid
- •Risk: without careful loops, outputs devolve into ‘slop’
- •Agents increase willingness to undertake larger rewrites and more ambitious PRs
- 9:44 – 11:54
Team dynamics in the agent era: bigger gaps, more prototypes, still small teams
Simon argues coding tools amplify differences between engineers, raising the ceiling dramatically while leaving the floor similar. Internally, the org becomes more chaotic in a positive way—more prototypes, higher-fidelity experiments, and larger PRs—while still favoring small tiger teams.
- •Impact is driven by tool fluency; individuals can be 100–1000x in output
- •Ceiling rises more than the minimum bar changes
- •More messy/chaotic execution: many prototypes and more ambitious PRs
- •Design team’s high-fidelity ‘design playground’ as an example of rapid iteration
- 11:54 – 12:49
Safety and quality: PR reviews, demanding tests, and avoiding vibe coding
Sarah asks about risky areas and whether everything is fair game. Simon explains that reviews remain mandatory, PRs are larger (often agent-written), and the standard is stronger end-to-end testing and safe deployment practices—shifting humans into careful specification and verification roles.
- •All PRs still reviewed; agent-written changes tend to be larger/more complex
- •Better testing is both possible and increasingly demanded
- •Focus on specifying changes precisely and defining verification loops
- •Not just ‘vibe coding’: safe deployment and confidence-building are explicit goals
- 12:49 – 14:37
From “agent didn’t work” to shipping: personal agent + custom autonomous agents
Simon recounts several failed attempts to build an agent before models and tooling were ready. Notion ultimately shipped a personal agent with broad Notion access, then launched custom agents that start with no permissions and can run autonomously in the background (including Slack-connected workflows).
- •Notion tried to build an agent 3–4 times before it became genuinely useful
- •Personal agent shipped Aug/Sep (last fall) with access to user-permitted resources
- •Custom agents launched recently: named, permissioned, and autonomous
- •Examples: Slack channel agent filing tasks; report agent combining workspace + web research
- 14:37 – 15:39
Agents that can bootstrap capabilities by writing code
Simon extends the agent definition: coding is a core tool that lets agents create new integrations and connect to data sources on demand. He frames coding agents as a foundational ‘kernel’ for more general intelligence and as a practical way to add deterministic logic to knowledge-work automation.
- •Notion agents as broader agents: code-writing as a first-class tool
- •Bootstrapping: build missing integrations, deploy them, and then use them
- •Coding as deterministic logic representation to complement probabilistic models
- •View that ‘AGI will be a coding agent’ and why that matters for product design
- 15:39 – 17:34
Notion as the “Switzerland” for models: multi-model strategy incl. open source
Asked how Notion competes amid labs and platform giants, Simon positions Notion as model-agnostic. Customers want flexibility as models shift monthly; Notion aims to offer easy access to the best options, including rapidly improving and cheaper open-source models.
- •Three-layer landscape: labs, software platforms, infrastructure
- •Notion’s stance: model-agnostic ‘Switzerland’ to avoid lock-in
- •Open-source models (including strong Chinese models) as key options
- •Cheaper models enable broader use cases while keeping frontier models available
- 17:34 – 19:11
Designing APIs for an agent customer: markdown dialect + SQLite over verbose JSON
Simon explains that agents are effectively a new type of API consumer, forcing Notion to redesign interfaces for token efficiency and model-friendliness. Notion moved away from verbose block JSON toward an enhanced markdown dialect for pages, and uses SQLite for database interactions to match model priors.
- •Agents as a new ‘customer’ requiring different API ergonomics
- •Problem: default block JSON is verbose and token-inefficient for models
- •Solution: enhanced markdown dialect for reading/writing Notion pages
- •Databases via SQLite so agents can query/operate in a familiar, compact format
- 19:11 – 20:10
Building agent-friendly interfaces empirically: ‘agent user research’ and eval loops
They discuss how Notion learned what makes APIs better for agents: experimentation, first-principles thinking about training priors, and constant iteration. Simon describes ‘infinite access’ to the agent for testing and the ability to script and scale evaluation.
- •Approach blends empirical trials with first-principles about model priors
- •Optimize for fewer tokens, clearer patterns, and reliable agent loops
- •‘User research’ is chatting with the agent; always available for feedback
- •Scriptable access enables scaled testing and ongoing evaluation
- 20:10 – 24:50
Simon’s agentic workflows: always-on coding agents + personal Notion agents in daily life
Simon shares his personal setup, including CLI-based coding agents he keeps running continuously, often overnight, and sometimes for days. He also uses Notion’s personal and custom agents for operational intelligence and automation, like email triage and routing internal bug/feedback reports.
- •Preference for CLI tools (Claude Code/Codex) and running many agents continuously
- •Overnight workflow: feed enough tasks so agents are still working by morning
- •Email triage custom agent: learns preferences via an editable ‘memory’ page
- •Internal feedback/bug routing agent: learns rules over time and files tasks to teams
- 24:50 – 26:00
Adoption beyond engineering: workshops, hackathons, and lowering the prompt barrier
Sarah asks how Notion helps non-technical teams build agent intuition. Simon describes internal workshops and hackathons, highlighting the People team as a strong adopter; the main hurdle is getting started and understanding basics like prompting, triggers, and agent ‘wakeup’ mechanics.
- •Workshops/hackathons to teach agent concepts and kickstart use cases
- •People team as an example of high adoption and strong workflow fit
- •Biggest barrier: initial unfamiliarity with prompts, triggers, and agent operation
- •Once past the barrier, the interface feels intuitive and human-like
- 26:00 – 27:27
Notion’s shift: from a tool for human work to a tool for managing agents
They return to the ‘Tools for Thought’ framing and how AI changes Notion’s core purpose. Simon describes a fundamental shift: Notion is still built on the same primitives (docs and databases), but now optimized for coordinating swarms of agents—where structured coordination (e.g., Kanban) matters more than chat threads.
- •Pre-AI goal: best tool for humans doing work directly
- •New goal: best tool for humans managing agents doing work
- •Docs and databases remain essential primitives; agents ‘love’ markdown
- •Coordination at scale: boards/structure beat hundreds of chat threads
- 27:27 – 29:02
How Simon’s building changed: from writing code to managing agents and verification
Simon closes by describing the personal shift in his craft over the last months: he no longer types code. His role is now defining end-to-end tasks, ensuring verification, monitoring for failure modes, and serving as the final reviewer rather than the primary implementer.
- •Simon hasn’t written code since last summer; he designs tasks instead
- •Workflow progression: typing → assistance → agents execute while he verifies
- •Human role becomes outer-loop manager, monitor, and final quality gate
- •Emphasis on end-to-end verification and catching ‘off-rails’ behavior early
