← Teardowns

How Notion AI Is Actually Built on Top of Notion

A technical breakdown of how Notion AI works under the hood — the block model, embeddings, RAG pipeline — and whether it's actually cloneable.

The block model is the actual product, AI is a feature bolted onto it

Everyone treats Notion AI like it's a chatbot pasted into a docs app. It's not, and understanding why matters if you're trying to size up how hard this is to clone. Notion's core data model is a graph of blocks — every paragraph, bullet, database row, and toggle is a node with a parent, children, and a type. Pages are just blocks that happen to render as full documents. This block graph has existed since 2016, long before AI was a checkbox on the roadmap.

That block graph is what makes Notion AI feel native instead of tacked-on. When you ask AI to summarize a page, it's not scraping rendered HTML — it's walking the block tree, respecting nesting, tables, and database properties, and reconstructing structured context. When AI writes back into your doc, it's not pasting a blob of text, it's inserting new block nodes at the right position in the tree, with the right formatting inherited. Any clone that starts from 'let's wrap GPT in a text editor' will nail the demo and fail the moment someone tries it on a real page with nested databases, synced blocks, and linked views.

Where the AI actually lives: a separate service, not a client-side hack

Notion AI isn't running in your browser tab calling OpenAI directly with your API key. There's a dedicated backend service that sits between the client and the model providers (Notion has used a mix of OpenAI and Anthropic models depending on the task and cost profile). This service does the boring but critical work: authentication, workspace permission checks, rate limiting, prompt construction, and — crucially — deciding what content the model is even allowed to see.

That permission check is non-trivial and it's the part most side projects skip entirely. Notion workspaces have granular sharing: a page can be visible to one person, a team, or the whole org, and permissions cascade through the block tree with overrides. Before AI can use a page as context (for Q&A, for example), the backend has to resolve the effective permission for the requesting user against that specific block subtree in real time. Get this wrong and you leak private HR docs into a marketing intern's AI summary. This is the unglamorous infrastructure that never shows up in a demo video but is the difference between a toy and a product a company can trust with its internal wiki.

Search and Q&A run on retrieval, not on stuffing the whole workspace into a prompt

'Ask AI' answering questions across your entire workspace is the feature people find most impressive, and it's also the most misunderstood. Notion isn't sending your whole workspace into a context window — that would be slow, expensive, and blow past token limits instantly for any team with thousands of pages. It's classic retrieval-augmented generation: content gets chunked (roughly at the block or section level, respecting document structure rather than blind character splitting), embedded into vectors, and stored in a vector index alongside metadata like last-edited time and permissions.

When you ask a question, the query gets embedded, the system does a similarity search to pull the most relevant chunks, filters them against your permissions, and only then constructs a prompt with that narrowed context plus the question. The quality of Notion AI's answers depends heavily on chunking strategy — chunk too small and you lose context, too large and retrieval gets noisy and expensive. Keeping that index fresh as thousands of users edit pages every second, across a graph structure rather than flat documents, is a genuinely hard distributed systems problem, not a weekend RAG tutorial.

Why this is technically cloneable in spirit but painful in practice

On oneprompt's technical-cloneability axis, Notion AI scores as 'yes, but not in a weekend.' The individual pieces — a block-based rich text editor, an LLM wrapper service, a RAG pipeline over embeddings — are all things a competent team can build with today's tools. You could prompt your way to a passable clone of the AI-writes-into-a-doc experience in a day using an off-the-shelf editor framework and an LLM API.

The gap shows up at scale and at the edges: real-time collaborative editing with conflict resolution across a block tree, permission-aware retrieval, incremental re-indexing on every edit across millions of workspaces, and latency budgets tight enough that AI autocomplete doesn't feel laggy. None of that is exotic technology, but it's a lot of unglamorous engineering that doesn't show up in a screenshot. If you're evaluating 'could I prompt-clone this,' the honest answer is: the AI layer, yes, fairly quickly; the underlying block/sync engine it depends on, no — that's years of accumulated edge-case handling.

The real moat isn't the model, it's the data already sitting in your workspace

This is where oneprompt's second axis — business moat — matters more than the tech. Notion AI's advantage has almost nothing to do with which LLM it calls this quarter. OpenAI, Anthropic, Google — these are interchangeable plumbing that Notion can and does swap based on cost and quality. The actual moat is that your team's entire knowledge base, wiki, meeting notes, project trackers, and specs already live inside Notion's block graph, structured and permissioned, before AI ever gets involved.

A competitor building 'Notion AI but better' has to solve two problems at once: build an equally good editor and convince your whole company to migrate years of interlinked pages and databases into it. Migration cost for a company-wide wiki with hundreds of cross-linked pages, embedded databases, and permission structures is brutal — nobody wants to be the person who breaks the finance team's linked database views during a switch. AI features are a retention multiplier on top of that existing lock-in, not the lock-in itself. Clone the AI feature and you've built a nice demo; you haven't touched the reason people stay.

What a serious clone attempt would actually need to get right

If you're sizing this up as a build-vs-clone decision, separate the two axes cleanly: the AI plumbing is a solved-problem stack you can assemble quickly with modern tools, but it's worthless without the underlying structured content graph and the switching costs that keep users from leaving. Notion spent nearly a decade building the boring block-graph infrastructure before AI made it look flashy. That sequencing is the actual lesson, not the prompt engineering.

  • A real block-tree data model with parent/child relationships and typed nodes, not a flat markdown string with AI sprinkled on top.
  • Permission resolution that runs on every retrieval call, scoped to the specific blocks being surfaced, not just workspace-level access checks.
  • A chunking and re-indexing pipeline that updates incrementally on edits, not a nightly batch job that leaves AI answers stale.
  • Model-agnostic prompt orchestration so you're not locked into one provider's pricing or rate limits as usage scales.
  • Enough existing user content and workspace lock-in that the AI feature has something valuable to retrieve from — an empty workspace with great RAG is still useless.

Want the same teardown for any site?

Analyze a site →